A major objective for Uniswap Governance this year is deploying Uniswap v3 on a broad set of high-quality EVM chains. This document explains why the lack of scalable cross-chain governance is currently an impediment to this goal, and proposes we select a bridge technology partner to build a solution. We outline our process for evaluating a vendor and next steps.
Contents
Authors
Laura Lotti & Toby Shorin (Other Internet) Image by Yitong Zhong (VectorDAO)
Uniswap V3 is deployed to Polygon, Arbitrum, and Optimism, with Celo, Moonbeam, and Gnosis Chain deploying soon. To enable Ethereum’s Uniswap deployment to govern all instances, each chain must have a messaging bridge for propagating governance decisions from Ethereum L1 to the remote chain’s instance of Uniswap V3 (“cross-chain governance”). Of these 6 deployments, there are 5 different messaging bridges used to execute governance decisions on each of the chains.
What this currently means is that each new proposal containing protocol parameter changes must be rewritten for each separate bridge and project, requiring custom code and separate votes, and potentially multiple proposal processes. In short, managing governance will become cost-prohibitive and complex as Uniswap scales.
While the volume of governance that pertains to cross-chain parameters is still low compared to protocols with more on-chain parameters, we anticipate that governance activity will increase in the future. Notably, the addition of further fee tiers specific to different chains, or the activation of pool-specific fee switches, would likely bring an increase in proposal volume.
Scaling Uniswap cross-chain governance is a multifaceted problem. Solving it in a “feature-complete” way would require several pieces of work.
Conversely, what should be “out of scope” for such an initiative?
⚠️ 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.
With these criteria in mind, we felt that an initial project should at least cover items 1, 2, and 3 above.
We call this the Universal Governance Module (UGM). Below, we explain our process for evaluating potential software vendors to implement the UGM.
Uniswap governance proposal #7 saw Flipside Analytics propose itself as a premiere service provider to Uniswap Protocol, in a move that caused concern and ultimately the retraction of the proposal. University blockchain clubs are often “used” by protocol diplomats and service providers for their delegated voting power without taking an opinionated stance.
To avoid these failures, we see the need for an independent party like Other Internet to evaluate vendors and nominate one. At the same time, we also want to ensure the process happens with the community’s awareness and acknowledgment.
Below we list the steps we’ve taken so far and where we are at in the process, along with our evaluation criteria for potential bridge partners.
Where we’ve been
Where we are now
Next steps
When evaluating potential bridge providers, several considerations must be taken into account. (Our thanks to Stevie Woofwoof from Osmosis, from whom we’ve adapted a similar list of questions.)
Technical Features
Team & Contractual Details
Vendor Lock-in
One possible cause for concern is that enshrining any single bridge provider will lead to vendor lock-in. Why is vendor lock-in problematic? If bridging UNI tokens were planned, the possibility of bridge fees being turned on might be a concern. But there is no plan to do so today.
Cryptocurrency discourse often advocates against “platform lock-in,” and such a perspective weights against crowning any single technology provider. But governance UX is no less important than the UX of the native swap application. Were Uniswap Labs itself engaged with governance, they would likely build, acquire, or solicit a bridge provider to develop a universal solution. In their absence, we see it as within our mandate to do the same.
Finally, Uniswap’s importance in the crypto ecosystem and its well-known brand give it significant leverage. Willingness to select a single vendor means we are in a strong position to solicit additional value-add services and long-term arrangements with any given partner.
L2 Native Bridge Security
Using the native bridges provided by L2s is considered preferable to alternative bridge providers, because A) their security is tied to that of the underlying chain and B) the incentive alignment of L2 teams’ reputation being staked on their chains’ security is thought to lead to better security.
On the other hand, most new EVM chains have not built their own bridging solution (Solana, Moonbeam, etc) and are already relying on third party bridges. This means we will still see fragmentation of governance bridges without a generalized solution, increasing the complexity of multichain decision making going forward. We believe this weighs toward the use of a single provider.
At this point in the process, we’d like to get overall feedback from the community on this issue, and any recommendations for additional bridge evaluation criteria we should be using. Please send us your recommendations within 7 days from this post to allow us to reach out to teams and complete our evaluation in a timely manner.
If you are interested in providing additional technical expertise to our review process, we’re happy to have more collaborators and reviewers on the comparison work. Please reply to this thread or send us a DM at twitter.com/otherinternet__ if you’d like to help.
Sam Hart, Funding Program at Interchain Foundation (Other Internet) Raf Solari, CTO at Tally (Independent Technical Advisor) Arr00, Engineer at Compound (Independent Technical Advisor) Getty Hill, Co-founder at GFX Labs (Uniswap Delegate) Robert Leshner, CEO at Compound Labs (Uniswap Delegate) Medha Kothari, Analyst, and Jesse Walden, Partner at Variant Fund (Uniswap Delegate, Investor) Larry Sukernik, Co-founder at Reverie (Uniswap Delegate) Erin Koen, Governance Lead at Avant Garde Finance (Uniswap Delegate)
A major objective for Uniswap Governance this year is deploying Uniswap v3 on a broad set of high-quality EVM chains. This document explains why the lack of scalable cross-chain governance is currently an impediment to this goal, and proposes we select a bridge technology partner to build a solution. We outline our process for evaluating a vendor and next steps.
Contents
Authors
Laura Lotti & Toby Shorin (Other Internet) Image by Yitong Zhong (VectorDAO)
Uniswap V3 is deployed to Polygon, Arbitrum, and Optimism, with Celo, Moonbeam, and Gnosis Chain deploying soon. To enable Ethereum’s Uniswap deployment to govern all instances, each chain must have a messaging bridge for propagating governance decisions from Ethereum L1 to the remote chain’s instance of Uniswap V3 (“cross-chain governance”). Of these 6 deployments, there are 5 different messaging bridges used to execute governance decisions on each of the chains.
What this currently means is that each new proposal containing protocol parameter changes must be rewritten for each separate bridge and project, requiring custom code and separate votes, and potentially multiple proposal processes. In short, managing governance will become cost-prohibitive and complex as Uniswap scales.
While the volume of governance that pertains to cross-chain parameters is still low compared to protocols with more on-chain parameters, we anticipate that governance activity will increase in the future. Notably, the addition of further fee tiers specific to different chains, or the activation of pool-specific fee switches, would likely bring an increase in proposal volume.
Scaling Uniswap cross-chain governance is a multifaceted problem. Solving it in a “feature-complete” way would require several pieces of work.
Conversely, what should be “out of scope” for such an initiative?
⚠️ 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.
With these criteria in mind, we felt that an initial project should at least cover items 1, 2, and 3 above.
We call this the Universal Governance Module (UGM). Below, we explain our process for evaluating potential software vendors to implement the UGM.
Uniswap governance proposal #7 saw Flipside Analytics propose itself as a premiere service provider to Uniswap Protocol, in a move that caused concern and ultimately the retraction of the proposal. University blockchain clubs are often “used” by protocol diplomats and service providers for their delegated voting power without taking an opinionated stance.
To avoid these failures, we see the need for an independent party like Other Internet to evaluate vendors and nominate one. At the same time, we also want to ensure the process happens with the community’s awareness and acknowledgment.
Below we list the steps we’ve taken so far and where we are at in the process, along with our evaluation criteria for potential bridge partners.
Where we’ve been
Where we are now
Next steps
When evaluating potential bridge providers, several considerations must be taken into account. (Our thanks to Stevie Woofwoof from Osmosis, from whom we’ve adapted a similar list of questions.)
Technical Features
Team & Contractual Details
Vendor Lock-in
One possible cause for concern is that enshrining any single bridge provider will lead to vendor lock-in. Why is vendor lock-in problematic? If bridging UNI tokens were planned, the possibility of bridge fees being turned on might be a concern. But there is no plan to do so today.
Cryptocurrency discourse often advocates against “platform lock-in,” and such a perspective weights against crowning any single technology provider. But governance UX is no less important than the UX of the native swap application. Were Uniswap Labs itself engaged with governance, they would likely build, acquire, or solicit a bridge provider to develop a universal solution. In their absence, we see it as within our mandate to do the same.
Finally, Uniswap’s importance in the crypto ecosystem and its well-known brand give it significant leverage. Willingness to select a single vendor means we are in a strong position to solicit additional value-add services and long-term arrangements with any given partner.
L2 Native Bridge Security
Using the native bridges provided by L2s is considered preferable to alternative bridge providers, because A) their security is tied to that of the underlying chain and B) the incentive alignment of L2 teams’ reputation being staked on their chains’ security is thought to lead to better security.
On the other hand, most new EVM chains have not built their own bridging solution (Solana, Moonbeam, etc) and are already relying on third party bridges. This means we will still see fragmentation of governance bridges without a generalized solution, increasing the complexity of multichain decision making going forward. We believe this weighs toward the use of a single provider.
At this point in the process, we’d like to get overall feedback from the community on this issue, and any recommendations for additional bridge evaluation criteria we should be using. Please send us your recommendations within 7 days from this post to allow us to reach out to teams and complete our evaluation in a timely manner.
If you are interested in providing additional technical expertise to our review process, we’re happy to have more collaborators and reviewers on the comparison work. Please reply to this thread or send us a DM at twitter.com/otherinternet__ if you’d like to help.
Sam Hart, Funding Program at Interchain Foundation (Other Internet) Raf Solari, CTO at Tally (Independent Technical Advisor) Arr00, Engineer at Compound (Independent Technical Advisor) Getty Hill, Co-founder at GFX Labs (Uniswap Delegate) Robert Leshner, CEO at Compound Labs (Uniswap Delegate) Medha Kothari, Analyst, and Jesse Walden, Partner at Variant Fund (Uniswap Delegate, Investor) Larry Sukernik, Co-founder at Reverie (Uniswap Delegate) Erin Koen, Governance Lead at Avant Garde Finance (Uniswap Delegate)
Hello. I am unsure where to post this, but want to post this some place besides Twitter. I'm curious as to if this is an Exploit in the Contract/wallets or if Admin is allowing the movement of UNI of Several Millions of USD from more than a handful of addresses recently. Wallet: 0x1a9c8182c09f50c8318d769245bea52c32be35bc
Hello. I am unsure where to post this, but want to post this some place besides Twitter. I'm curious as to if this is an Exploit in the Contract/wallets or if Admin is allowing the movement of UNI of Several Millions of USD from more than a handful of addresses recently. Wallet: 0x1a9c8182c09f50c8318d769245bea52c32be35bc
We've really appreciated the incredible outreach from stakeholders in the community looking to learn more about our UGM implementation. Following up with a full proposal to aid thorough evaluation from other teams and delegates:
We've really appreciated the incredible outreach from stakeholders in the community looking to learn more about our UGM implementation. Following up with a full proposal to aid thorough evaluation from other teams and delegates:
Due to the inherent security risks of cross chain messaging, the Uniswap Universal Module (UGM) should leverage the most secure cross chain solution that is enabled by the most proficient and qualified technical team. LayerZero has superior security properties to other solutions. Further, LayerZero Labs has demonstrated rigor in designing and parameterizing the highest standard of security required to protect the Uniswap governance process. As such, we respectfully submit that LayerZero Protocol is the singularly credible and secure implementation of the UGM.
LayerZero’s key securities properties are as follows (see Technical Structure for more information). LayerZero is an open and permissionless Omnichain Interoperability Protocol designed for lightweight message passing across chains. Our technology provides authentic and guaranteed message delivery with configurable trustlessness; the protocol is implemented as a set of gas-efficient, non-upgradable smart contracts.
LayerZero is currently live on 10 chains including Ethereum, Polygon, Arbitrum, Optimism, BNB Chain, Avalanche, and Fantom, and on testnet and undergoing audit on 16 chains including Moonbeam, Gnosis Chain, and Solana among other non-EVM chains.
LayerZero Labs has consistently operated with the principle that security is the highest priority. In the last two years, LayerZero Labs:
During this time, LayerZero Labs has built a world-class team of engineers, community managers, and product strategists and earned the support of investors and advisors including FTX, a16z, Sequoia, and Uniswap Labs. LayerZero remains the only battle-tested major cross-chain communications provider to never be hacked and is trusted by the top protocols and dApps across DeFi, NFT infrastructure, and gaming.
LayerZero is a lightweight universal messaging interface that allows developers to seamlessly interact with contracts across dozens of blockchains. LayerZero Endpoints rely on an innovative architecture to trustlessly relay messages between chains.
(Above: Communication flow in a single LayerZero cross-chain transaction)
In a single call, paying only source gas, users can send a message (or a bundle of messages) to contracts on any supported chain. Thus, users are able to create a single contract that is capable of interacting simultaneously across multiple chains via our messaging primitive.
LayerZero achieves this in a secure and decentralized manner by using a Relayer and Oracle architecture. From a decentralization and security perspective, this model never moves information through middle-chains. With no transport chain dependencies or reliance on disparate validation methods, users can be confident in the authenticity of cross-chain messages and transactions.
Per the RFC, Uniswap governance will continue to be housed on Ethereum and via a single contract, messages are sent simultaneously from the LayerZero endpoint on Ethereum to endpoints on Polygon, Optimism, Arbitrum, and any other future deployed chain.
As described below, LayerZero offers an unmatched combination of security, efficiency, and application-specific configurability for the UGM. Competing protocols offer some of these advantages but none offer all of them simultaneously.
LayerZero enables Uniswap to commit to application-specific feature upgrades. The importance of this capability cannot be understated. Generalized upgradeability has led to hundreds of millions in losses! Most smart contracts used in competing cross-chain solutions are upgradable. As a result, it doesn't matter how secure their infrastructure is, if a protocol is updated to add a new feature and there’s a bug in the update, every other application that interacts with the smart contract is automatically exposed to new smart contract risk. There is no way for applications to reject these upgrades. This vulnerability due to upgradeable smart contract design is inherent to every other competing cross-chain provider and is exemplified by the recent Nomad hack.
LayerZero uses immutable contracts with a novel opt-in validation library upgrade system that gives any application the choice to either accept or reject any or all future LayerZero protocol enhancements. It is impossible for LayerZero Labs or any multisig process to force changes to a Uniswap integration once it’s established. Applications with high security standards have the choice to accept protocol enhancements or not.
For example, LayerZero could add libraries to support ZK-rollups, optimistic roll ups, or gas optimization to enhance core protocol functionality. Uniswap can choose to not accept such library upgrades or selectively upgrade depending on governance belief in new best practices in security or industry research at the community’s discretion. Our team’s belief is that current security practices should not and will not be the industry best practices 10 years from now. As researchers move the industry forward, so should the security model of cross-chain infrastructure. LayerZero’s opt-in validation library empowers applications to evolve with cutting-edge research and industry best practices.
As evidenced by the recent surge of bridge exploits and more than one billion dollars of value lost, application-specific feature upgrades are essential for Uniswap’s UGM. This feature prevents human error in future protocol upgrades that risk affecting every integrated application by default, and prevents attacks from the entity pushing the upgrade, regardless of the security of their off-chain infrastructure.
LayerZero is the only generic messaging protocol that puts the power and ability to control the development of Uniswap’s omnichain functionality back in the hands of the Uniswap protocol - where it belongs.
LayerZero’s Oracle and Relayer systems lead to the best possible security outcomes for end users. Specific to cross-chain governance, competing middle-chain bridge designs can be censored by malicious actors looking to tamper with a vote or governance proposal. If a malicious actor takes control of the middle-chain they can reorder, choose not to deliver specific messages sent across chains, or fraudulently attest to any decision therefore completely rigging any governance vote.
LayerZero’s bifurcated Oracle-Relayer security model ensures that either every message is censored or none are, rendering message censoring unattractive for malicious actors. Oracles and Relayers cannot censor messages without censoring all messages due to the sequential nonce ordered enforcement on the receiving chain. As a result, if an attacker obtained control of the Oracle and Relayer, and succeeded in censoring a message, every subsequent message would also be censored and the vote would stop. No hard stop would occur and Uniswap could expediently resolve the issue. Uniswap would simply select a new Oracle or Relayer and messaging would resume. This bifurcated model prevents effective collusion amongst potential malicious actors and ensures the ongoing operation of governance.
In addition to our built-in security model, LayerZero leads the industry in cross-chain security with Pre-Crime, a proprietary module which launched in April and currently secures Stargate. In fact, the Wormhole/Jump team recommended two major security updates in a recent blog post: Reconciliation / Global Accounting and Emergency Shutdown. Pre-Crime was built to address these issues and can be used to verify that all votes cast on Ethereum are not double counted on other chains.
For Uniswap cross-chain governance, infallible on-chain votes and results are critical to protect the integrity of any changes that are pushed to the Uniswap code base.
Cross-chain governance is a complex challenge to address as it requires preserving a seamless, unified UX. LayerZero the earliest integration partner to enable cross-chain governance for one of the largest DeFi protocols (soon-to-be announced).
From this custom development, we have designed the Omnichain Governance Module, a framework for out-of-the-box cross-chain governance which enables easy implementation of a simple, cost-effective solution attuned to governance-specific needs around accuracy, consistency, and lightweight engineering. Our module offers an optional time-lock function which acts as a backstop for decisions in case of malicious activity.
In addition to the security benefits described above, LayerZero underlying design is a series of immutable (i.e., non-upgradeable) smart contracts. This immutability is critical in infrastructure design as the attack surface becomes exponentially larger when cross-chain contracts are upgradeable and universal. This has become increasingly evident in the spate of recent cross-chain bridge exploits. Unfortunately, every competing proposal on this thread is predicated on a structure with entirely upgradeable contracts.
LayerZero offers what no other cross-chain solution can: control over security parameters at the application layer. When using our Omnichain Governance Module, Uniswap has the ability to configure off-chain infrastructure, block confirmation parameters, and Oracle/Relayer selection. Uniswap governance is never forced to opt-in to any permanent off-chain infrastructure configuration and has the ability to change parameters at will for security and user-experience purposes among others. The unique ability to deploy different Oracle, Relayer, and infrastructure configurations allows users to optimize for both cost and trustlessness. For example, Uniswap can choose to run one of the entities (Oracle or Relayer) as a group of major UNI token holders, further decentralizing their governance and endowing the most incentivized members of the community with partial ownership of security.
Uniswap governance decisions and upgrade calls should not be locked into the same security parameters that apply to low-value token transfers. We view the ability to own security parameters at the governance level to be mission critical for major protocols and DAOs.
LayerZero was designed and built with efficiency as a first principle cost where other solutions have high transaction costs. As the volume of Uniswap governance increases, a lightweight and modular cross-chain solution will be critical for scaling. LayerZero messages are extremely lightweight and have one of the smallest possible headers today. Four fields and ~100k gas interactions on both send() and receive() functions are already deployed with upcoming opt-in libraries set to reduce gas consumption to sub-100k.
LayerZero is capable of both singular and batched cross-chain communication. By combining batched transactions with the most efficient messaging primitive, LayerZero allows Uniswap to house core governance on Ethereum and push decisions to all relevant chains at the lowest possible cost.
LayerZero Labs is well-resourced and fully prepared to support the entire Omnichain Governance Module implementation process from start to finish including commissioning of multiple audits and providing on-going product and smart contract support to Uniswap.
Our technology is ready to be implemented and is fully developed as an out-of-the-box solution. We have developed a thorough UGM support plan and will provide:
LayerZero Labs will provide a dedicated team of engineers, an Integration Lead, and our CTO Ryan Zarick to the Uniswap UGM. Ryan will be the primary point of contact for the Uniswap Community and provide complete developer support and full protocol resources to write all contracts and fund multiple full audits from the most trusted auditors in the world. Ryan will also encourage and maintain open and ongoing collaboration with the Community during and after the integration process for cross-chain governance in perpetuity.
Under the Lead’s guidance, this team of dedicated engineers will implement special projects including the development of a unique graphical user interface for delegates, proposers, and community members to monitor the Uniswap governance process and state across chains.
We respectfully submit that for the reasons outlined above, LayerZero offers the greatest security properties and the singularly credible solution for the UGM RFC. LayerZero Labs has a degree of commitment to security that is unmatched in the space; the team has already implemented a full solution for cross-chain governance and would bring this expertise to the UGM. Should this proposal pass, LayerZero will begin implementation immediately.
Hi all, just giving our 2 cents. We’re from Swim, a liquidity protocol that aims to support a multi-chain world. When building our protocol, we also had to decide upon a solution for our cross-chain communication, and ended up choosing Wormhole.
When comparing vendors our most important considerations were security, decentralization, and reliability. In this regard we ranked Wormhole as the clear winner here due to their high quality guardians and secure POS design.
Hi all, just giving our 2 cents. We’re from Swim, a liquidity protocol that aims to support a multi-chain world. When building our protocol, we also had to decide upon a solution for our cross-chain communication, and ended up choosing Wormhole.
When comparing vendors our most important considerations were security, decentralization, and reliability. In this regard we ranked Wormhole as the clear winner here due to their high quality guardians and secure POS design.
We have utilized Wormhole’s Portal Bridge to offer users the ability to swap native assets while abstracting away wrapped assets for the user. The Wormhole team has been very helpful from the start, and continue to provide us with a great deal of resources and support as we leverage their innovation to produce innovations of our own.
For example, Wormhole’s Payload 3 is a core component of Swim’s relayer- the Propeller, which will enable single-click smart contract calls without sacrificing decentralization.
We couldn’t be happier with our decision to build on Wormhole, whilst sharing with the team the same passion for innovation, decentralization and transparency in the cross-chain space.
Hey @jamico , I'm Aksh from the LI.FI team, LI.FI is a cross-chain bridge aggregator that has aggregated most of the bridges that have made proposals here. As an aggregator, we are in touch with most of the bridges in the ecosystem and we treat them all fairly. We don't have our own bridge nor do we have our own messaging protocol we're working on. We'd love to be the neutral party here that can facilitate the conversations along with Other Internet.
Why are we the best to do this? Like Uniswap, we don't take any fees from the underlying bridges, thus, we're unbiased here to begin with. We believe all bridges are needed as we don't need an optimistic bridge-level security to transfer $3 worth assets. No matter which bridge Uniswap decides to go with, we'll be getting the same amount of volume from our users who want to bridge UNI token through LI.FI(if UNI is ever bridged across).
Hey @jamico , I'm Aksh from the LI.FI team, LI.FI is a cross-chain bridge aggregator that has aggregated most of the bridges that have made proposals here. As an aggregator, we are in touch with most of the bridges in the ecosystem and we treat them all fairly. We don't have our own bridge nor do we have our own messaging protocol we're working on. We'd love to be the neutral party here that can facilitate the conversations along with Other Internet.
Why are we the best to do this? Like Uniswap, we don't take any fees from the underlying bridges, thus, we're unbiased here to begin with. We believe all bridges are needed as we don't need an optimistic bridge-level security to transfer $3 worth assets. No matter which bridge Uniswap decides to go with, we'll be getting the same amount of volume from our users who want to bridge UNI token through LI.FI(if UNI is ever bridged across).
We're an infrastructure project that uses the underlying bridges and provides the best route to the users. To do this we have to research about all the bridges in the ecosystem and understand the trust/security assumptions of them all, along with their gas efficiencies.
Please refer to this article by our team here which describes the various trust assumptions of all the different bridges in the ecosystem. In our blog we also have written about the security assumptions of all the bridges we have integrated so far.
Next steps We'd love to read all the proposals obtained by @tobyshorin that aren't in this thread to make a fair, structured and open analysis about all the various bridging solutions for UGM. We are happy to collab with Other Internet here to look into their existing analyses and make this open to the Uniswap community.
Hey @tobyshorin, can you please post the existing proposals to Github/Notion or anywhere you feel best and paste the link here? Ty. Looking forward to collaborating with you to be helpful to the iconic Uniswap protocol :).
Aksh LI.FI
It’s becoming clear that this process is not serving Uniswap well. Rather than rush to meet an arbitrary deadline, it’s more important that we solicit proposals from the best providers and give them a fair chance to compete. That doesn’t seem to be happening here. It’s also important that the community has the chance to hear these proposals and engage with the providers openly, rather than have the process intermediated behind closed doors.
We’ve seen public RFPs work well in other communities, including most recently with Osmosis, which selected its own bridge provider via an open competition. Compound also successfully hired an auditor through a public RFP earlier this year. In those cases we've seen neutral third parties like Reverie and GFX Labs step forward to administer the process in an open but structured way. We think a similar process would serve Uniswap well here, and propose shifting gears in this direction.
It’s becoming clear that this process is not serving Uniswap well. Rather than rush to meet an arbitrary deadline, it’s more important that we solicit proposals from the best providers and give them a fair chance to compete. That doesn’t seem to be happening here. It’s also important that the community has the chance to hear these proposals and engage with the providers openly, rather than have the process intermediated behind closed doors.
We’ve seen public RFPs work well in other communities, including most recently with Osmosis, which selected its own bridge provider via an open competition. Compound also successfully hired an auditor through a public RFP earlier this year. In those cases we've seen neutral third parties like Reverie and GFX Labs step forward to administer the process in an open but structured way. We think a similar process would serve Uniswap well here, and propose shifting gears in this direction.
Jeff a16z
We've really appreciated the incredible outreach from stakeholders in the community looking to learn more about our UGM implementation. Following up with a full proposal to aid thorough evaluation from other teams and delegates:
We've really appreciated the incredible outreach from stakeholders in the community looking to learn more about our UGM implementation. Following up with a full proposal to aid thorough evaluation from other teams and delegates:
Due to the inherent security risks of cross chain messaging, the Uniswap Universal Module (UGM) should leverage the most secure cross chain solution that is enabled by the most proficient and qualified technical team. LayerZero has superior security properties to other solutions. Further, LayerZero Labs has demonstrated rigor in designing and parameterizing the highest standard of security required to protect the Uniswap governance process. As such, we respectfully submit that LayerZero Protocol is the singularly credible and secure implementation of the UGM.
LayerZero’s key securities properties are as follows (see Technical Structure for more information). LayerZero is an open and permissionless Omnichain Interoperability Protocol designed for lightweight message passing across chains. Our technology provides authentic and guaranteed message delivery with configurable trustlessness; the protocol is implemented as a set of gas-efficient, non-upgradable smart contracts.
LayerZero is currently live on 10 chains including Ethereum, Polygon, Arbitrum, Optimism, BNB Chain, Avalanche, and Fantom, and on testnet and undergoing audit on 16 chains including Moonbeam, Gnosis Chain, and Solana among other non-EVM chains.
LayerZero Labs has consistently operated with the principle that security is the highest priority. In the last two years, LayerZero Labs:
During this time, LayerZero Labs has built a world-class team of engineers, community managers, and product strategists and earned the support of investors and advisors including FTX, a16z, Sequoia, and Uniswap Labs. LayerZero remains the only battle-tested major cross-chain communications provider to never be hacked and is trusted by the top protocols and dApps across DeFi, NFT infrastructure, and gaming.
LayerZero is a lightweight universal messaging interface that allows developers to seamlessly interact with contracts across dozens of blockchains. LayerZero Endpoints rely on an innovative architecture to trustlessly relay messages between chains.
(Above: Communication flow in a single LayerZero cross-chain transaction)
In a single call, paying only source gas, users can send a message (or a bundle of messages) to contracts on any supported chain. Thus, users are able to create a single contract that is capable of interacting simultaneously across multiple chains via our messaging primitive.
LayerZero achieves this in a secure and decentralized manner by using a Relayer and Oracle architecture. From a decentralization and security perspective, this model never moves information through middle-chains. With no transport chain dependencies or reliance on disparate validation methods, users can be confident in the authenticity of cross-chain messages and transactions.
Per the RFC, Uniswap governance will continue to be housed on Ethereum and via a single contract, messages are sent simultaneously from the LayerZero endpoint on Ethereum to endpoints on Polygon, Optimism, Arbitrum, and any other future deployed chain.
As described below, LayerZero offers an unmatched combination of security, efficiency, and application-specific configurability for the UGM. Competing protocols offer some of these advantages but none offer all of them simultaneously.
LayerZero enables Uniswap to commit to application-specific feature upgrades. The importance of this capability cannot be understated. Generalized upgradeability has led to hundreds of millions in losses! Most smart contracts used in competing cross-chain solutions are upgradable. As a result, it doesn't matter how secure their infrastructure is, if a protocol is updated to add a new feature and there’s a bug in the update, every other application that interacts with the smart contract is automatically exposed to new smart contract risk. There is no way for applications to reject these upgrades. This vulnerability due to upgradeable smart contract design is inherent to every other competing cross-chain provider and is exemplified by the recent Nomad hack.
LayerZero uses immutable contracts with a novel opt-in validation library upgrade system that gives any application the choice to either accept or reject any or all future LayerZero protocol enhancements. It is impossible for LayerZero Labs or any multisig process to force changes to a Uniswap integration once it’s established. Applications with high security standards have the choice to accept protocol enhancements or not.
For example, LayerZero could add libraries to support ZK-rollups, optimistic roll ups, or gas optimization to enhance core protocol functionality. Uniswap can choose to not accept such library upgrades or selectively upgrade depending on governance belief in new best practices in security or industry research at the community’s discretion. Our team’s belief is that current security practices should not and will not be the industry best practices 10 years from now. As researchers move the industry forward, so should the security model of cross-chain infrastructure. LayerZero’s opt-in validation library empowers applications to evolve with cutting-edge research and industry best practices.
As evidenced by the recent surge of bridge exploits and more than one billion dollars of value lost, application-specific feature upgrades are essential for Uniswap’s UGM. This feature prevents human error in future protocol upgrades that risk affecting every integrated application by default, and prevents attacks from the entity pushing the upgrade, regardless of the security of their off-chain infrastructure.
LayerZero is the only generic messaging protocol that puts the power and ability to control the development of Uniswap’s omnichain functionality back in the hands of the Uniswap protocol - where it belongs.
LayerZero’s Oracle and Relayer systems lead to the best possible security outcomes for end users. Specific to cross-chain governance, competing middle-chain bridge designs can be censored by malicious actors looking to tamper with a vote or governance proposal. If a malicious actor takes control of the middle-chain they can reorder, choose not to deliver specific messages sent across chains, or fraudulently attest to any decision therefore completely rigging any governance vote.
LayerZero’s bifurcated Oracle-Relayer security model ensures that either every message is censored or none are, rendering message censoring unattractive for malicious actors. Oracles and Relayers cannot censor messages without censoring all messages due to the sequential nonce ordered enforcement on the receiving chain. As a result, if an attacker obtained control of the Oracle and Relayer, and succeeded in censoring a message, every subsequent message would also be censored and the vote would stop. No hard stop would occur and Uniswap could expediently resolve the issue. Uniswap would simply select a new Oracle or Relayer and messaging would resume. This bifurcated model prevents effective collusion amongst potential malicious actors and ensures the ongoing operation of governance.
In addition to our built-in security model, LayerZero leads the industry in cross-chain security with Pre-Crime, a proprietary module which launched in April and currently secures Stargate. In fact, the Wormhole/Jump team recommended two major security updates in a recent blog post: Reconciliation / Global Accounting and Emergency Shutdown. Pre-Crime was built to address these issues and can be used to verify that all votes cast on Ethereum are not double counted on other chains.
For Uniswap cross-chain governance, infallible on-chain votes and results are critical to protect the integrity of any changes that are pushed to the Uniswap code base.
Cross-chain governance is a complex challenge to address as it requires preserving a seamless, unified UX. LayerZero the earliest integration partner to enable cross-chain governance for one of the largest DeFi protocols (soon-to-be announced).
From this custom development, we have designed the Omnichain Governance Module, a framework for out-of-the-box cross-chain governance which enables easy implementation of a simple, cost-effective solution attuned to governance-specific needs around accuracy, consistency, and lightweight engineering. Our module offers an optional time-lock function which acts as a backstop for decisions in case of malicious activity.
In addition to the security benefits described above, LayerZero underlying design is a series of immutable (i.e., non-upgradeable) smart contracts. This immutability is critical in infrastructure design as the attack surface becomes exponentially larger when cross-chain contracts are upgradeable and universal. This has become increasingly evident in the spate of recent cross-chain bridge exploits. Unfortunately, every competing proposal on this thread is predicated on a structure with entirely upgradeable contracts.
LayerZero offers what no other cross-chain solution can: control over security parameters at the application layer. When using our Omnichain Governance Module, Uniswap has the ability to configure off-chain infrastructure, block confirmation parameters, and Oracle/Relayer selection. Uniswap governance is never forced to opt-in to any permanent off-chain infrastructure configuration and has the ability to change parameters at will for security and user-experience purposes among others. The unique ability to deploy different Oracle, Relayer, and infrastructure configurations allows users to optimize for both cost and trustlessness. For example, Uniswap can choose to run one of the entities (Oracle or Relayer) as a group of major UNI token holders, further decentralizing their governance and endowing the most incentivized members of the community with partial ownership of security.
Uniswap governance decisions and upgrade calls should not be locked into the same security parameters that apply to low-value token transfers. We view the ability to own security parameters at the governance level to be mission critical for major protocols and DAOs.
LayerZero was designed and built with efficiency as a first principle cost where other solutions have high transaction costs. As the volume of Uniswap governance increases, a lightweight and modular cross-chain solution will be critical for scaling. LayerZero messages are extremely lightweight and have one of the smallest possible headers today. Four fields and ~100k gas interactions on both send() and receive() functions are already deployed with upcoming opt-in libraries set to reduce gas consumption to sub-100k.
LayerZero is capable of both singular and batched cross-chain communication. By combining batched transactions with the most efficient messaging primitive, LayerZero allows Uniswap to house core governance on Ethereum and push decisions to all relevant chains at the lowest possible cost.
LayerZero Labs is well-resourced and fully prepared to support the entire Omnichain Governance Module implementation process from start to finish including commissioning of multiple audits and providing on-going product and smart contract support to Uniswap.
Our technology is ready to be implemented and is fully developed as an out-of-the-box solution. We have developed a thorough UGM support plan and will provide:
LayerZero Labs will provide a dedicated team of engineers, an Integration Lead, and our CTO Ryan Zarick to the Uniswap UGM. Ryan will be the primary point of contact for the Uniswap Community and provide complete developer support and full protocol resources to write all contracts and fund multiple full audits from the most trusted auditors in the world. Ryan will also encourage and maintain open and ongoing collaboration with the Community during and after the integration process for cross-chain governance in perpetuity.
Under the Lead’s guidance, this team of dedicated engineers will implement special projects including the development of a unique graphical user interface for delegates, proposers, and community members to monitor the Uniswap governance process and state across chains.
We respectfully submit that for the reasons outlined above, LayerZero offers the greatest security properties and the singularly credible solution for the UGM RFC. LayerZero Labs has a degree of commitment to security that is unmatched in the space; the team has already implemented a full solution for cross-chain governance and would bring this expertise to the UGM. Should this proposal pass, LayerZero will begin implementation immediately.
Hi all, just giving our 2 cents. We’re from Swim, a liquidity protocol that aims to support a multi-chain world. When building our protocol, we also had to decide upon a solution for our cross-chain communication, and ended up choosing Wormhole.
When comparing vendors our most important considerations were security, decentralization, and reliability. In this regard we ranked Wormhole as the clear winner here due to their high quality guardians and secure POS design.
Hi all, just giving our 2 cents. We’re from Swim, a liquidity protocol that aims to support a multi-chain world. When building our protocol, we also had to decide upon a solution for our cross-chain communication, and ended up choosing Wormhole.
When comparing vendors our most important considerations were security, decentralization, and reliability. In this regard we ranked Wormhole as the clear winner here due to their high quality guardians and secure POS design.
We have utilized Wormhole’s Portal Bridge to offer users the ability to swap native assets while abstracting away wrapped assets for the user. The Wormhole team has been very helpful from the start, and continue to provide us with a great deal of resources and support as we leverage their innovation to produce innovations of our own.
For example, Wormhole’s Payload 3 is a core component of Swim’s relayer- the Propeller, which will enable single-click smart contract calls without sacrificing decentralization.
We couldn’t be happier with our decision to build on Wormhole, whilst sharing with the team the same passion for innovation, decentralization and transparency in the cross-chain space.
Hey @jamico , I'm Aksh from the LI.FI team, LI.FI is a cross-chain bridge aggregator that has aggregated most of the bridges that have made proposals here. As an aggregator, we are in touch with most of the bridges in the ecosystem and we treat them all fairly. We don't have our own bridge nor do we have our own messaging protocol we're working on. We'd love to be the neutral party here that can facilitate the conversations along with Other Internet.
Why are we the best to do this? Like Uniswap, we don't take any fees from the underlying bridges, thus, we're unbiased here to begin with. We believe all bridges are needed as we don't need an optimistic bridge-level security to transfer $3 worth assets. No matter which bridge Uniswap decides to go with, we'll be getting the same amount of volume from our users who want to bridge UNI token through LI.FI(if UNI is ever bridged across).
Hey @jamico , I'm Aksh from the LI.FI team, LI.FI is a cross-chain bridge aggregator that has aggregated most of the bridges that have made proposals here. As an aggregator, we are in touch with most of the bridges in the ecosystem and we treat them all fairly. We don't have our own bridge nor do we have our own messaging protocol we're working on. We'd love to be the neutral party here that can facilitate the conversations along with Other Internet.
Why are we the best to do this? Like Uniswap, we don't take any fees from the underlying bridges, thus, we're unbiased here to begin with. We believe all bridges are needed as we don't need an optimistic bridge-level security to transfer $3 worth assets. No matter which bridge Uniswap decides to go with, we'll be getting the same amount of volume from our users who want to bridge UNI token through LI.FI(if UNI is ever bridged across).
We're an infrastructure project that uses the underlying bridges and provides the best route to the users. To do this we have to research about all the bridges in the ecosystem and understand the trust/security assumptions of them all, along with their gas efficiencies.
Please refer to this article by our team here which describes the various trust assumptions of all the different bridges in the ecosystem. In our blog we also have written about the security assumptions of all the bridges we have integrated so far.
Next steps We'd love to read all the proposals obtained by @tobyshorin that aren't in this thread to make a fair, structured and open analysis about all the various bridging solutions for UGM. We are happy to collab with Other Internet here to look into their existing analyses and make this open to the Uniswap community.
Hey @tobyshorin, can you please post the existing proposals to Github/Notion or anywhere you feel best and paste the link here? Ty. Looking forward to collaborating with you to be helpful to the iconic Uniswap protocol :).
Aksh LI.FI
It’s becoming clear that this process is not serving Uniswap well. Rather than rush to meet an arbitrary deadline, it’s more important that we solicit proposals from the best providers and give them a fair chance to compete. That doesn’t seem to be happening here. It’s also important that the community has the chance to hear these proposals and engage with the providers openly, rather than have the process intermediated behind closed doors.
We’ve seen public RFPs work well in other communities, including most recently with Osmosis, which selected its own bridge provider via an open competition. Compound also successfully hired an auditor through a public RFP earlier this year. In those cases we've seen neutral third parties like Reverie and GFX Labs step forward to administer the process in an open but structured way. We think a similar process would serve Uniswap well here, and propose shifting gears in this direction.
It’s becoming clear that this process is not serving Uniswap well. Rather than rush to meet an arbitrary deadline, it’s more important that we solicit proposals from the best providers and give them a fair chance to compete. That doesn’t seem to be happening here. It’s also important that the community has the chance to hear these proposals and engage with the providers openly, rather than have the process intermediated behind closed doors.
We’ve seen public RFPs work well in other communities, including most recently with Osmosis, which selected its own bridge provider via an open competition. Compound also successfully hired an auditor through a public RFP earlier this year. In those cases we've seen neutral third parties like Reverie and GFX Labs step forward to administer the process in an open but structured way. We think a similar process would serve Uniswap well here, and propose shifting gears in this direction.
Jeff a16z
@tobyshorin, we’re excited to see this proposal live.
After examining the RFC by Uniswap and respectfully reading the proposals submitted by others, we’re excited to submit Wormhole’s proposal. The Wormhole team is committed to building out the full solution, commissioning the audits, and providing on-going product and smart contract support to Uniswap.
@tobyshorin, we’re excited to see this proposal live.
After examining the RFC by Uniswap and respectfully reading the proposals submitted by others, we’re excited to submit Wormhole’s proposal. The Wormhole team is committed to building out the full solution, commissioning the audits, and providing on-going product and smart contract support to Uniswap.
A quick intro to Wormhole — Wormhole is a leading cross-chain interoperability protocol, allowing generic messaging between 14 (and soon to be many more) heterogenous blockchains. Since launch on mainnet in August 2021, 1.2 million messages have been transmitted. Some are regular messages (e.g. oracle data), some are token bridges, and all of it comes through organic usage — no incentives.
There are three key reasons why we think Wormhole offers the best solution for Uniswap’s cross-chain governance:
As a reminder, Uniswap’s goals are twofold: house governance on Ethereum, then message and execute these decisions on both Ethereum and the other supported chains.
At a high level, governance decisions continue being made on Ethereum using the existing governance tools of Uniswap. These decisions get passed into the Wormhole endpoint on Ethereum, where they get attested by the Wormhole guardian network. These Wormhole-attested messages can then be verified on the respective chains and the decisions be queued for execution.
To see this in more depth, consider the technical model below:
This model is very easy to maintain and enhance. Subject to Uniswap governance approval, receiver contracts can be upgraded over time. Moreover, anyone can deploy the Wormhole receiver contracts on new destination chains to process VAAs without waiting for Wormhole to formally support those chains. Furthermore, Wormhole’s solution is low cost and efficient — the submission and subsequent verification of Wormhole message costs only 11k and 130k gas, respectively.
Details on how the contract interfaces and message protocol could look like can be seen here.
If this proposal passes, Wormhole will promptly execute on all four asks of Uniswap’s UGM proposal (the first of which is already complete!):
Given that we have already proposed a clear spec with very lightweight contracts, the smart contract development can be executed promptly following coordinated audits — thus, the UI would be the biggest new lift engineering-wise. With a robust group of contributors that includes engineers, product designers, and smart contract auditors, we are confident our integration will be smooth and seamless. As Director of the Wormhole Foundation and co-founder of Certus One, I will personally manage the effort from start to finish with on-call support from the wider group of 25 engineers.
Wormhole relies on a PoA consensus with 19 guardians. Each guardian runs their own node for each chain and holds equal weight in governance and voting. Of the 19 guardians, Wormhole requires more than two-thirds to reach consensus and pass verification - thus, we assume that at least one-third our of guardian set is honest. Our guardians set is comprised of the leading PoS validators with billions in active delegations across the biggest PoS chains — P2P, Chorus One, Everstake, to name a few. However, despite Wormhole’s high degree of decentralization, we remain resolute on improving our trust assumptions — as such, we are placing heavy investments in moving towards a completely trustless system based on zero knowledge proofs.
In just the last 90-days alone, Wormhole has transmitted 500k messages. Wormhole has handled some of the recent volatile periods in DeFi with ease, facilitating 44k messages in just one day. Our tried and tested protocol has gained the trust of some of the most reputable developers in the space — a number of protocols are currently building cross-chain swaps, DEXs, money market protocols, yield aggregators, wallets, gaming, oracles, perps, launchpads and many more.
Finally, we recognize that Wormhole has earned some press for the hack in February of this year —we believe Wormhole is stronger for it. Wormhole, for instance, has one of the most generous bug bounty programs in crypto—over $10 million and counting—and a series of careful audits. Wormhole will continue along both of these fronts so as to uphold high standards of security for its users and protocols across supported ecosystems. Related to this, the Timelock contract is meant to be one final safeguard against an exploit, giving Uniswap valuable time to revoke a hacked message. This serves as an extra failsafe against any smart contract bugs or faulty cross-chain governance proposals.
While Wormhole has thus far reached fourteen destination chains, as diverse as Solana, Avalanche, and Aurora — the governance module we’ve outlined above is freed of dependencies on integrations with the destination chain, message relayers, and all other forms of infrastructure and development. As long as the core Wormhole network can be relied upon to sign the VAAs observed on Ethereum, all other development details can be ignored. And we believe the core Wormhole network can indeed be relied upon for this function, due to its high degree of decentralization.
We look forward to engaging with the Uniswap community on our proposal.
Thanks for drafting this proposal @tobyshorin. It’s great to see Other Internet taking such an active role in the ongoing evolution of Uniswap’s governance.
I’m Bryan, co-founder of LayerZero Labs. The need for a ‘feature complete’ solution to Uniswap’s cross-chain governance is the exact type of problem LayerZero was built to solve.
Thanks for drafting this proposal @tobyshorin. It’s great to see Other Internet taking such an active role in the ongoing evolution of Uniswap’s governance.
I’m Bryan, co-founder of LayerZero Labs. The need for a ‘feature complete’ solution to Uniswap’s cross-chain governance is the exact type of problem LayerZero was built to solve.
LayerZero is an open and permissionless Omnichain Interoperability Protocol designed for lightweight message passing across chains. Given our unique generic messaging protocol design, anyone can participate in the network as a Relayer or an Oracle. Our technology provides authentic and guaranteed message delivery with configurable trustlessness; the protocol is implemented as a set of gas-efficient, non-upgradable smart contracts.
In the last two years, LayerZero:
During this time, we have built a world-class team of engineers, community managers, and product strategists and earned the support of investors and advisors from FTX, a16z, Sequoia, and Uniswap Labs.
Universal Governance with LayerZero
Currently Uniswap is deployed on 6 different chains and employs 5 messaging bridges to execute governance decisions on each chain. As Other Internet described, moving Uniswap to cross-chain governance will require additional developer resources to write and interact with custom interfaces for each chain.
Today, LayerZero is live on 10 mainnet chains including Ethereum, Polygon, Arbitrum, Optimism, BNB Chain, Avalanche, and Fantom and live on 16 testnet chains including Celo, Moonbeam, and Solana among other non-EVM chains.
Instead of rewriting new governance proposals for separate bridges and new chains, integration with LayerZero empowers the Community to write one proposal with zero additional custom code to pass on all active chains. The LayerZero interface was designed for ease-of-use. Implementing a single ABI with standardized call data for creating proposals on multiple chains is as straightforward as implementing a single function type from the enacting contract on source chain; the developer simply writes a send() and receive() function with the passage of a generic bytes array. This enables proposers to deploy their proposal code to selected or all chains in one proposal.
As the volume of Uniswap governance increases, a lightweight and modular cross-chain solution will be critical for cost efficiency and scaling properties. LayerZero is extremely lightweight and has one of the smallest possible headers (4 fields) and ~100k gas interactions on both send() and receive() with improvement libraries soon to be released which reduce gas to sub 100k.
LayerZero has seen strong developer adoption from 700 contracts live on testnet 3 months ago to over 4100 today. We pride ourselves on the technology’s incredible ease-of-use for both delegates and proposers, transforming a 10 min long process of 40-50 clicks, into 2-3 clicks and reducing a user ordeal of maintaining multiple gas tokens to requiring only source chain gas for cross-chain transactions. LayerZero’s cross-chain governance implementation offers one of the lowest total gas consumed in cost: ~100k gas on source and ~80k on destination including gas for code execution. LayerZero Labs is well-resourced and willing to collaborate with Uniswap Labs to maintain their implementation in perpetuity.
Notably, protocols which integrate with LayerZero own all of their own end bridge contracts. For example, Uniswap would own and have full control over their implementation contracts. From its inception, LayerZero was designed to provide protocols like Uniswap with a unified interface across all chains (both EVM and non-EVM).
The LayerZero team’s success is tied to the success of our partners. With billions in TVL, billions transferred, and many of the most reputable projects in the world already building on top of our infrastructure, we believe LayerZero should be strongly considered to be the provider enabling Uniswap’s Universal Governance Module.
Dedicated Advisory
LayerZero will provide a dedicated team of engineers, an Integration Lead, and our CTO Ryan Zarick to the Uniswap UGM. Ryan will be the primary point of contact for the Uniswap Community and provide complete developer support and full protocol resources to write all contracts and fund multiple full audits from the most trusted auditors in the world. Ryan will also encourage and maintain open and ongoing collaboration with the Community during and after the integration process for cross-chain governance in perpetuity.
Under the Integration Lead’s guidance, this team of dedicated engineers will implement special projects including the development of a unique graphical user interface for delegates, proposers, and community members monitoring the Uniswap governance process and state across chains.
Next Steps
LayerZero already has full support for generalized message passing and has been consistently used at scale with billions in both TVL and transactional volume since launch. In the next year, LayerZero will go live on 10+ more chains (EVM and non-EVM) and welcomes collaboration with the Uniswap Community on specific roadmap milestones and new feature priorities.
LayerZero has the immediate resources to provide a white-glove developer experience and full integration support and coverage including multiple security audits on all contracts.
We would love to be considered by the DAO as the single best solution for Uniswap to achieve seamless, secure omni-chain governance and would like to be part of a robust evaluation process run by the DAO.
For more information on our architecture and implementation, you can dig into our docs here. We look forward to hearing from the Community.
We at Magpie Protocol have integrated with Wormhole where we utilize their generic message protocol for publishing messages across supported chains, before integrating wormhole we have played around with various cross chain communication protocols that are currently live and choose wormhole for a number of reasons:
CoreBridgepayload in bytes typeThanks @tobyshorin. This is an important initiative. Uniswap would certainly benefit from a more standardized solution for cross-chain deployments. And Other Internet (being an excellent steward of the protocol) is well suited to help administer a process like this.
A few thoughts on the proposed structure.
Thanks @tobyshorin. This is an important initiative. Uniswap would certainly benefit from a more standardized solution for cross-chain deployments. And Other Internet (being an excellent steward of the protocol) is well suited to help administer a process like this.
A few thoughts on the proposed structure.
1) Timing. Selecting a bridge provider is an important decision for Uniswap. It’s critical that we allow providers enough time to review the RFP and submit high quality bids. While we appreciate the need for efficiency, the proposed timeline (2 weeks) is realistically too short to accomplish this goal. Let's align on the overall structure / criteria first and then we can set a timeline that makes sense.
2) Tokenholder consent. While it makes sense for Other Internet to help administer the process, the ultimate decision should be made by the community. In our view a structure whereby: a) Open Internet helps coordinate bids / runs the process; and b) the community selects the ultimate winner strikes the right balance overall. This will ensure that the process remains organized and efficient but also retains broad-based token holder consent.
3) Compound precedent. A useful precedent here is Compound’s recent RFP process. In that case, Reverie ran a competitive process to hire a security auditor for the protocol. The process produced multiple high-quality bids from top audit firms, including Open Zeppelin, Trail of Bits, ChainSecurity, and more. Reverie helped to shepherd the process and allowed the community to evaluate the bids over the course of several weeks (including over community calls, forum posts, etc). After weighing the various proposals, the community collectively voted and picked a winner. Though it had its challenges, this community-led approach led to fair and competitive process that served Compound well in the end. We think something similar makes sense here.
Happy to help coordinate and support.
Jeff a16z
@tobyshorin, we’re excited to see this proposal live.
After examining the RFC by Uniswap and respectfully reading the proposals submitted by others, we’re excited to submit Wormhole’s proposal. The Wormhole team is committed to building out the full solution, commissioning the audits, and providing on-going product and smart contract support to Uniswap.
@tobyshorin, we’re excited to see this proposal live.
After examining the RFC by Uniswap and respectfully reading the proposals submitted by others, we’re excited to submit Wormhole’s proposal. The Wormhole team is committed to building out the full solution, commissioning the audits, and providing on-going product and smart contract support to Uniswap.
A quick intro to Wormhole — Wormhole is a leading cross-chain interoperability protocol, allowing generic messaging between 14 (and soon to be many more) heterogenous blockchains. Since launch on mainnet in August 2021, 1.2 million messages have been transmitted. Some are regular messages (e.g. oracle data), some are token bridges, and all of it comes through organic usage — no incentives.
There are three key reasons why we think Wormhole offers the best solution for Uniswap’s cross-chain governance:
As a reminder, Uniswap’s goals are twofold: house governance on Ethereum, then message and execute these decisions on both Ethereum and the other supported chains.
At a high level, governance decisions continue being made on Ethereum using the existing governance tools of Uniswap. These decisions get passed into the Wormhole endpoint on Ethereum, where they get attested by the Wormhole guardian network. These Wormhole-attested messages can then be verified on the respective chains and the decisions be queued for execution.
To see this in more depth, consider the technical model below:
This model is very easy to maintain and enhance. Subject to Uniswap governance approval, receiver contracts can be upgraded over time. Moreover, anyone can deploy the Wormhole receiver contracts on new destination chains to process VAAs without waiting for Wormhole to formally support those chains. Furthermore, Wormhole’s solution is low cost and efficient — the submission and subsequent verification of Wormhole message costs only 11k and 130k gas, respectively.
Details on how the contract interfaces and message protocol could look like can be seen here.
If this proposal passes, Wormhole will promptly execute on all four asks of Uniswap’s UGM proposal (the first of which is already complete!):
Given that we have already proposed a clear spec with very lightweight contracts, the smart contract development can be executed promptly following coordinated audits — thus, the UI would be the biggest new lift engineering-wise. With a robust group of contributors that includes engineers, product designers, and smart contract auditors, we are confident our integration will be smooth and seamless. As Director of the Wormhole Foundation and co-founder of Certus One, I will personally manage the effort from start to finish with on-call support from the wider group of 25 engineers.
Wormhole relies on a PoA consensus with 19 guardians. Each guardian runs their own node for each chain and holds equal weight in governance and voting. Of the 19 guardians, Wormhole requires more than two-thirds to reach consensus and pass verification - thus, we assume that at least one-third our of guardian set is honest. Our guardians set is comprised of the leading PoS validators with billions in active delegations across the biggest PoS chains — P2P, Chorus One, Everstake, to name a few. However, despite Wormhole’s high degree of decentralization, we remain resolute on improving our trust assumptions — as such, we are placing heavy investments in moving towards a completely trustless system based on zero knowledge proofs.
In just the last 90-days alone, Wormhole has transmitted 500k messages. Wormhole has handled some of the recent volatile periods in DeFi with ease, facilitating 44k messages in just one day. Our tried and tested protocol has gained the trust of some of the most reputable developers in the space — a number of protocols are currently building cross-chain swaps, DEXs, money market protocols, yield aggregators, wallets, gaming, oracles, perps, launchpads and many more.
Finally, we recognize that Wormhole has earned some press for the hack in February of this year —we believe Wormhole is stronger for it. Wormhole, for instance, has one of the most generous bug bounty programs in crypto—over $10 million and counting—and a series of careful audits. Wormhole will continue along both of these fronts so as to uphold high standards of security for its users and protocols across supported ecosystems. Related to this, the Timelock contract is meant to be one final safeguard against an exploit, giving Uniswap valuable time to revoke a hacked message. This serves as an extra failsafe against any smart contract bugs or faulty cross-chain governance proposals.
While Wormhole has thus far reached fourteen destination chains, as diverse as Solana, Avalanche, and Aurora — the governance module we’ve outlined above is freed of dependencies on integrations with the destination chain, message relayers, and all other forms of infrastructure and development. As long as the core Wormhole network can be relied upon to sign the VAAs observed on Ethereum, all other development details can be ignored. And we believe the core Wormhole network can indeed be relied upon for this function, due to its high degree of decentralization.
We look forward to engaging with the Uniswap community on our proposal.
Thanks for drafting this proposal @tobyshorin. It’s great to see Other Internet taking such an active role in the ongoing evolution of Uniswap’s governance.
I’m Bryan, co-founder of LayerZero Labs. The need for a ‘feature complete’ solution to Uniswap’s cross-chain governance is the exact type of problem LayerZero was built to solve.
Thanks for drafting this proposal @tobyshorin. It’s great to see Other Internet taking such an active role in the ongoing evolution of Uniswap’s governance.
I’m Bryan, co-founder of LayerZero Labs. The need for a ‘feature complete’ solution to Uniswap’s cross-chain governance is the exact type of problem LayerZero was built to solve.
LayerZero is an open and permissionless Omnichain Interoperability Protocol designed for lightweight message passing across chains. Given our unique generic messaging protocol design, anyone can participate in the network as a Relayer or an Oracle. Our technology provides authentic and guaranteed message delivery with configurable trustlessness; the protocol is implemented as a set of gas-efficient, non-upgradable smart contracts.
In the last two years, LayerZero:
During this time, we have built a world-class team of engineers, community managers, and product strategists and earned the support of investors and advisors from FTX, a16z, Sequoia, and Uniswap Labs.
Universal Governance with LayerZero
Currently Uniswap is deployed on 6 different chains and employs 5 messaging bridges to execute governance decisions on each chain. As Other Internet described, moving Uniswap to cross-chain governance will require additional developer resources to write and interact with custom interfaces for each chain.
Today, LayerZero is live on 10 mainnet chains including Ethereum, Polygon, Arbitrum, Optimism, BNB Chain, Avalanche, and Fantom and live on 16 testnet chains including Celo, Moonbeam, and Solana among other non-EVM chains.
Instead of rewriting new governance proposals for separate bridges and new chains, integration with LayerZero empowers the Community to write one proposal with zero additional custom code to pass on all active chains. The LayerZero interface was designed for ease-of-use. Implementing a single ABI with standardized call data for creating proposals on multiple chains is as straightforward as implementing a single function type from the enacting contract on source chain; the developer simply writes a send() and receive() function with the passage of a generic bytes array. This enables proposers to deploy their proposal code to selected or all chains in one proposal.
As the volume of Uniswap governance increases, a lightweight and modular cross-chain solution will be critical for cost efficiency and scaling properties. LayerZero is extremely lightweight and has one of the smallest possible headers (4 fields) and ~100k gas interactions on both send() and receive() with improvement libraries soon to be released which reduce gas to sub 100k.
LayerZero has seen strong developer adoption from 700 contracts live on testnet 3 months ago to over 4100 today. We pride ourselves on the technology’s incredible ease-of-use for both delegates and proposers, transforming a 10 min long process of 40-50 clicks, into 2-3 clicks and reducing a user ordeal of maintaining multiple gas tokens to requiring only source chain gas for cross-chain transactions. LayerZero’s cross-chain governance implementation offers one of the lowest total gas consumed in cost: ~100k gas on source and ~80k on destination including gas for code execution. LayerZero Labs is well-resourced and willing to collaborate with Uniswap Labs to maintain their implementation in perpetuity.
Notably, protocols which integrate with LayerZero own all of their own end bridge contracts. For example, Uniswap would own and have full control over their implementation contracts. From its inception, LayerZero was designed to provide protocols like Uniswap with a unified interface across all chains (both EVM and non-EVM).
The LayerZero team’s success is tied to the success of our partners. With billions in TVL, billions transferred, and many of the most reputable projects in the world already building on top of our infrastructure, we believe LayerZero should be strongly considered to be the provider enabling Uniswap’s Universal Governance Module.
Dedicated Advisory
LayerZero will provide a dedicated team of engineers, an Integration Lead, and our CTO Ryan Zarick to the Uniswap UGM. Ryan will be the primary point of contact for the Uniswap Community and provide complete developer support and full protocol resources to write all contracts and fund multiple full audits from the most trusted auditors in the world. Ryan will also encourage and maintain open and ongoing collaboration with the Community during and after the integration process for cross-chain governance in perpetuity.
Under the Integration Lead’s guidance, this team of dedicated engineers will implement special projects including the development of a unique graphical user interface for delegates, proposers, and community members monitoring the Uniswap governance process and state across chains.
Next Steps
LayerZero already has full support for generalized message passing and has been consistently used at scale with billions in both TVL and transactional volume since launch. In the next year, LayerZero will go live on 10+ more chains (EVM and non-EVM) and welcomes collaboration with the Uniswap Community on specific roadmap milestones and new feature priorities.
LayerZero has the immediate resources to provide a white-glove developer experience and full integration support and coverage including multiple security audits on all contracts.
We would love to be considered by the DAO as the single best solution for Uniswap to achieve seamless, secure omni-chain governance and would like to be part of a robust evaluation process run by the DAO.
For more information on our architecture and implementation, you can dig into our docs here. We look forward to hearing from the Community.
We at Magpie Protocol have integrated with Wormhole where we utilize their generic message protocol for publishing messages across supported chains, before integrating wormhole we have played around with various cross chain communication protocols that are currently live and choose wormhole for a number of reasons:
CoreBridgepayload in bytes typeThanks @tobyshorin. This is an important initiative. Uniswap would certainly benefit from a more standardized solution for cross-chain deployments. And Other Internet (being an excellent steward of the protocol) is well suited to help administer a process like this.
A few thoughts on the proposed structure.
Thanks @tobyshorin. This is an important initiative. Uniswap would certainly benefit from a more standardized solution for cross-chain deployments. And Other Internet (being an excellent steward of the protocol) is well suited to help administer a process like this.
A few thoughts on the proposed structure.
1) Timing. Selecting a bridge provider is an important decision for Uniswap. It’s critical that we allow providers enough time to review the RFP and submit high quality bids. While we appreciate the need for efficiency, the proposed timeline (2 weeks) is realistically too short to accomplish this goal. Let's align on the overall structure / criteria first and then we can set a timeline that makes sense.
2) Tokenholder consent. While it makes sense for Other Internet to help administer the process, the ultimate decision should be made by the community. In our view a structure whereby: a) Open Internet helps coordinate bids / runs the process; and b) the community selects the ultimate winner strikes the right balance overall. This will ensure that the process remains organized and efficient but also retains broad-based token holder consent.
3) Compound precedent. A useful precedent here is Compound’s recent RFP process. In that case, Reverie ran a competitive process to hire a security auditor for the protocol. The process produced multiple high-quality bids from top audit firms, including Open Zeppelin, Trail of Bits, ChainSecurity, and more. Reverie helped to shepherd the process and allowed the community to evaluate the bids over the course of several weeks (including over community calls, forum posts, etc). After weighing the various proposals, the community collectively voted and picked a winner. Though it had its challenges, this community-led approach led to fair and competitive process that served Compound well in the end. We think something similar makes sense here.
Happy to help coordinate and support.
Jeff a16z
First of all, I´d like to thank Toby and the peeps from the Other Internet for the comprehensive update of this topic.
I´d agree with the approach of rather being careful than sorry. Inherently, there is no need to rush things mainly in an environment as described by Tony in the update.
First of all, I´d like to thank Toby and the peeps from the Other Internet for the comprehensive update of this topic.
I´d agree with the approach of rather being careful than sorry. Inherently, there is no need to rush things mainly in an environment as described by Tony in the update.
This is Mo Dong from Celer Network. For some reason, in this forum I cannot post links and graphics which are needed for the proposal. So I am not able to post proposal here. Could forum admin help to fix it?
In the meantime, here is an url (please remove all spaces) that you can use to access the proposal. tinyurl. com/ mrcvw98b
Thank you for this RFC. This is Mo Dong from Celer. We will post our proposal shortly as part of vendor review process.
This is Mo Dong from Celer Network. For some reason, in this forum I cannot post links and graphics which are needed for the proposal. So I am not able to post proposal here. Could forum admin help to fix it?
In the meantime, here is an url (please remove all spaces) that you can use to access the proposal. tinyurl. com/ mrcvw98b
Thank you for this RFC. This is Mo Dong from Celer. We will post our proposal shortly as part of vendor review process.
Celer Network community would love to submit a proposal to be considered as a solution for UGM.
Celer Network community would love to submit a proposal to be considered as a solution for UGM.
Celer is a generalized blockchain interoperability protocol enabling a one-click user experience accessing tokens, DeFi, GameFi, NFTs, governance, and more across multiple chains. Developers can build inter-chain-native dApps using the Celer Inter-chain Message (IM) SDK to gain access to efficient liquidity utilization, coherent application logic, and shared states. There are 10+ cross-chain applications live today that are built with Celer IM on various use cases including governance and liquidity protocols. cBridge, an asset bridging application has processed $9.7b transaction volume across 31 chains for 200K users.
Celer IM based UGM is already live in production with FutureSwap since the end of April 2022. The reference implementation of UGM is very straightforward and we describe the high level flow here based on the application design pattern.
When a governance decision is made on Ethereum, the governance contract will call sendMessage of a “send box” contract which takes in the destination chain ids, message to be passed and destination contract addresses. The message will contain the serialized bytes of the governance decision.
This message will be synced with State Guardian Network, which is a Cosmos SDK based blockchain. Validators in SGN will witness the message and reach consensus on the Cosmos layer that this message indeeded exists and generate a stake-weighted multisignature attestation that is stored on the chain.
A message executor (can be run by Uniswap or run by validators of Celer Network) will collect this message and call executeMessage of a “receive box” contract. After necessary on-chain validation of the message, the message will be eventually relayed to the destination contract.
The validation, except for the generic checking of the validity of the signatures, also has two security models available to determine when the target contract will receive the message. The first security model is to directly pass the message on and rely fully on PoS security of the Cosmos chain.
However, in the case of low-frequency applications like UGM, we recommend using the second security model: an optimistic rollup-like security model. In this security model, every message that is passed onto the destination chain will be first put into a “quarantine zone” for a configurable period of time. During that quarantine period, every single validator in the SGN and the application executor (collectively, App Guardians) can monitor and cross-check the message arrived on the destination chain vs sent on the source chain. If there is any invariant mismatch, the message path will be cut off immediately and the message will not be executed. This changes the security assumption from “trust majority stake” to “trust any” with app developers capable of running one of the “any” App Guardians themselves. This is how FutureSwap implemented their cross-chain governance module.
Once the quarantine clock times out, the message will be executed by calling a standard interface on the destination governance contract. This will complete the UGM process.
With the complete walkthrough of the application scenario, we now respond more directly to each of the evaluation criteria in the RFP.
As discussed above, Celer’s generalized message cross-chain solution comes with two security models and we recommend using the optimistic rollup solution here. More context on Celer’s security models:
Celer comes with two security models that each app and users are free to choose from on a per-tx basis.
By default, inter-chain dApps rely on the security of the State Guardian Network (a Cosmos Chain) by processing messages routed from another chain without delay. The SGN offers L1-blockchain level security just like Cosmos or Polygon with it being a Proof-of-Stake (PoS) blockchain built on Tendermint with CELR as the staking asset. If a guardian acts maliciously, its staked CELR will be slashed by the consensus protocol. This level of economic security is something that grows with the staked CELR’s value and is simply not available in simple Multi-signature or MPC/PoA-based solutions.
So, what happens if more than two thirds (in staked value) of the validators behave maliciously in the State Guardian Network? Although this is highly unlikely given the economical security and distributed nature of the validators in Celer Network, Celer does have a second security model, inspired by the Optimistic Rollup design, that works securely even under this worst-case scenario.
Instead of instantly processing a message routed by the SGN, a two-phase commit-confirm pattern is used to process any inter-chain message. Before any application consumes the message, the message has to be “committed” to the blockchain by SGN into a “quarantine zone” for a period of time. Only after the delay has passed, can this message be “confirmed” and pushed to the final destination application.
During this delay buffer, a dApp can run an App Guardian service to double-validate the message on the source chain and check the authenticity of the message committed in the quarantine zone. If the App Guardian detects any inconsistency, it can prevent the message from being processed before the time buffer expires. For application developers who cannot run an App Guardian themselves, they can commission the SGN nodes to undertake the task of an App Guardian. In that case, the security model is strengthened to a trust-any model for the SGN. Therefore, even under the worst-case scenario of the SGN consensus failure, inter-chain dApps built on top of Celer’s construct will still maintain safety property without any concern.
We estimate that the UGM cross-chain governance solution for Uniswap only requires about 150 LoC to implement the necessary smart contracts. We can provide a full reference implementation that is ready for review by the Uniswap community and security auditing firms. Another example of similar complexity is a full-fledged ERC-721 NFT bridge which has only 250 smart contract LoC.
Celer cBridge is already used by multiple developers for different use cases.
Some other examples below:
ChainHop, a composable cross-chain liquidity protocol built on top of Celer Network where users can swap A token on X chain to B token on Y chain with just one click. ChainHop actually integrates Celer Network and Uniswap on all supported chains. You can actually review the source code of ChainHop. This kind of fancy functionality only has less than 1000 loc. Similar use cases are Rubic and Swing.
Celer IM is widely applicable to build inter-chain DeFi applications as well. The decentralized derivatives protocol SynFutures is using Celer’s IM framework to support multi-blockchain futures trading, allowing users to leverage liquidity from any blockchain. Ooki, a powerful and fully decentralized margin trading, borrowing, and lending platform, is leveraging Celer IM to enable fee bridging among all of Ooki’s different blockchain deployments. Aperture, a cross-chain, community-driven marketplace for DeFi strategies, is leveraging Celer IM to enable one-click access to supported strategies for users from any blockchain. Solace, a decentralized insurance protocol that allows users to insure positions for over 180 DeFi protocols with one policy, is also integrating Celer IM for cross-chain insurance functionality. Of course, Celer IM can be used in many other use cases besides DeFi applications. Mystiko Network, the base layer of web3 that provides both connectivity and confidentiality to all blockchain data, transactions and applications, uses Celer IM to enable privacy protection against unwanted cross-chain data tracking and exploits.
Celer currently supports EVM-based chains that Uniswap supports or plans to support including Ethereum, Polygon, Arbitrum, and Optimism, Celo, Moonbeam, and Gnosis Chain. In addition, Celer supports some other EVM chains including Astar, BNB Chain, Avalanche, Fantom, Metis, Oasis Emerald, Evmos, Aurora, Moonriver, Boba Network, OKXChain, Heco, Ape Chain, Clover, Conflux, Crab Smart Chain, Kava EVM Co-Chain, Milkomeda Cardano, Nervos Godwoken, Ontology EVM, PlatON, REI Network, SX Network, Shiden and Swimmer Network.
For non-EVM based chains, Celer supports Flow blockchain and Cosmwasm chains such as Terra.
Solana is now on testnet.
Celer cBridge is highly efficient in gas consumption and has been optimized to do so. For example, the bridging gas costs between Arbitrum to Ethereum using Celer is about half of the official bridge.
We are happy to provide reference implementation and maintain such implementation in a white-clove service model. There might be some frontend module integration needed that we can closely work with the Uniswap team to complete.
Celer was initially founded in 2018 by four computer scientists with PhD degrees from MIT, UCBerkley, Princeton and UIUC with tens of years of industrial experience in networking security, operating systems and large-scale distributed systems. Throughout the long (crypto-term) history of Celer, no security incidents or hacks ever happened in any production software built by the Celer community. Overtime, Celer Network has now attracted many excellent community developers and becomes a decentralized community driven project that is focused on cross-chain interoperability.
Celer is a multi-chain operating system. Through Celer IM, developers can build inter-chain dApps using the Celer Inter-chain Message SDK with efficient liquidity utilization, coherent application logic, and shared states across multiple blockchains. Users of Celer-enabled dApps will enjoy the benefits of a diverse multi-blockchain ecosystem with the simplicity of a single-transaction UX from a single chain. Ultimately, the goal is to have developers using the existing Celer technology to abstract the concept of “multiple blockchain” away.
We believe Celer community has one of the best developer support processes through our strong network of community developers.
Finally, we thank Uniswap governance bodies for considering our submission to the RFP and we are also happy to discuss any other collaboration here.
Other Resources on Celer:
Celer Network community would love to submit a proposal to be considered as a solution for UGM.
Celer Network community would love to submit a proposal to be considered as a solution for UGM.
Celer is a generalized blockchain interoperability protocol enabling a one-click user experience accessing tokens, DeFi, GameFi, NFTs, governance, and more across multiple chains. Developers can build inter-chain-native dApps using the Celer Inter-chain Message (IM) SDK to gain access to efficient liquidity utilization, coherent application logic, and shared states. There are 10+ cross-chain applications live today that are built with Celer IM on various use cases including governance and liquidity protocols. cBridge, an asset bridging application has processed $9.7b transaction volume across 31 chains for 200K users.
Celer IM based UGM is already live in production with FutureSwap since the end of April 2022. The reference implementation of UGM is very straightforward and we describe the high level flow here based on the application design pattern.
When a governance decision is made on Ethereum, the governance contract will call sendMessage of a “send box” contract which takes in the destination chain ids, message to be passed and destination contract addresses. The message will contain the serialized bytes of the governance decision.
This message will be synced with State Guardian Network, which is a Cosmos SDK based blockchain. Validators in SGN will witness the message and reach consensus on the Cosmos layer that this message indeeded exists and generate a stake-weighted multisignature attestation that is stored on the chain.
A message executor (can be run by Uniswap or run by validators of Celer Network) will collect this message and call executeMessage of a “receive box” contract. After necessary on-chain validation of the message, the message will be eventually relayed to the destination contract.
The validation, except for the generic checking of the validity of the signatures, also has two security models available to determine when the target contract will receive the message. The first security model is to directly pass the message on and rely fully on PoS security of the Cosmos chain.
However, in the case of low-frequency applications like UGM, we recommend using the second security model: an optimistic rollup-like security model. In this security model, every message that is passed onto the destination chain will be first put into a “quarantine zone” for a configurable period of time. During that quarantine period, every single validator in the SGN and the application executor (collectively, App Guardians) can monitor and cross-check the message arrived on the destination chain vs sent on the source chain. If there is any invariant mismatch, the message path will be cut off immediately and the message will not be executed. This changes the security assumption from “trust majority stake” to “trust any” with app developers capable of running one of the “any” App Guardians themselves. This is how FutureSwap implemented their cross-chain governance module.
Once the quarantine clock times out, the message will be executed by calling a standard interface on the destination governance contract. This will complete the UGM process.
With the complete walkthrough of the application scenario, we now respond more directly to each of the evaluation criteria in the RFP.
As discussed above, Celer’s generalized message cross-chain solution comes with two security models and we recommend using the optimistic rollup solution here. More context on Celer’s security models:
Celer comes with two security models that each app and users are free to choose from on a per-tx basis.
By default, inter-chain dApps rely on the security of the State Guardian Network (a Cosmos Chain) by processing messages routed from another chain without delay. The SGN offers L1-blockchain level security just like Cosmos or Polygon with it being a Proof-of-Stake (PoS) blockchain built on Tendermint with CELR as the staking asset. If a guardian acts maliciously, its staked CELR will be slashed by the consensus protocol. This level of economic security is something that grows with the staked CELR’s value and is simply not available in simple Multi-signature or MPC/PoA-based solutions.
So, what happens if more than two thirds (in staked value) of the validators behave maliciously in the State Guardian Network? Although this is highly unlikely given the economical security and distributed nature of the validators in Celer Network, Celer does have a second security model, inspired by the Optimistic Rollup design, that works securely even under this worst-case scenario.
Instead of instantly processing a message routed by the SGN, a two-phase commit-confirm pattern is used to process any inter-chain message. Before any application consumes the message, the message has to be “committed” to the blockchain by SGN into a “quarantine zone” for a period of time. Only after the delay has passed, can this message be “confirmed” and pushed to the final destination application.
During this delay buffer, a dApp can run an App Guardian service to double-validate the message on the source chain and check the authenticity of the message committed in the quarantine zone. If the App Guardian detects any inconsistency, it can prevent the message from being processed before the time buffer expires. For application developers who cannot run an App Guardian themselves, they can commission the SGN nodes to undertake the task of an App Guardian. In that case, the security model is strengthened to a trust-any model for the SGN. Therefore, even under the worst-case scenario of the SGN consensus failure, inter-chain dApps built on top of Celer’s construct will still maintain safety property without any concern.
We estimate that the UGM cross-chain governance solution for Uniswap only requires about 150 LoC to implement the necessary smart contracts. We can provide a full reference implementation that is ready for review by the Uniswap community and security auditing firms. Another example of similar complexity is a full-fledged ERC-721 NFT bridge which has only 250 smart contract LoC.
Celer cBridge is already used by multiple developers for different use cases.
Some other examples below:
ChainHop, a composable cross-chain liquidity protocol built on top of Celer Network where users can swap A token on X chain to B token on Y chain with just one click. ChainHop actually integrates Celer Network and Uniswap on all supported chains. You can actually review the source code of ChainHop. This kind of fancy functionality only has less than 1000 loc. Similar use cases are Rubic and Swing.
Celer IM is widely applicable to build inter-chain DeFi applications as well. The decentralized derivatives protocol SynFutures is using Celer’s IM framework to support multi-blockchain futures trading, allowing users to leverage liquidity from any blockchain. Ooki, a powerful and fully decentralized margin trading, borrowing, and lending platform, is leveraging Celer IM to enable fee bridging among all of Ooki’s different blockchain deployments. Aperture, a cross-chain, community-driven marketplace for DeFi strategies, is leveraging Celer IM to enable one-click access to supported strategies for users from any blockchain. Solace, a decentralized insurance protocol that allows users to insure positions for over 180 DeFi protocols with one policy, is also integrating Celer IM for cross-chain insurance functionality. Of course, Celer IM can be used in many other use cases besides DeFi applications. Mystiko Network, the base layer of web3 that provides both connectivity and confidentiality to all blockchain data, transactions and applications, uses Celer IM to enable privacy protection against unwanted cross-chain data tracking and exploits.
Celer currently supports EVM-based chains that Uniswap supports or plans to support including Ethereum, Polygon, Arbitrum, and Optimism, Celo, Moonbeam, and Gnosis Chain. In addition, Celer supports some other EVM chains including Astar, BNB Chain, Avalanche, Fantom, Metis, Oasis Emerald, Evmos, Aurora, Moonriver, Boba Network, OKXChain, Heco, Ape Chain, Clover, Conflux, Crab Smart Chain, Kava EVM Co-Chain, Milkomeda Cardano, Nervos Godwoken, Ontology EVM, PlatON, REI Network, SX Network, Shiden and Swimmer Network.
For non-EVM based chains, Celer supports Flow blockchain and Cosmwasm chains such as Terra.
Solana is now on testnet.
Celer cBridge is highly efficient in gas consumption and has been optimized to do so. For example, the bridging gas costs between Arbitrum to Ethereum using Celer is about half of the official bridge.
We are happy to provide reference implementation and maintain such implementation in a white-clove service model. There might be some frontend module integration needed that we can closely work with the Uniswap team to complete.
Celer was initially founded in 2018 by four computer scientists with PhD degrees from MIT, UCBerkley, Princeton and UIUC with tens of years of industrial experience in networking security, operating systems and large-scale distributed systems. Throughout the long (crypto-term) history of Celer, no security incidents or hacks ever happened in any production software built by the Celer community. Overtime, Celer Network has now attracted many excellent community developers and becomes a decentralized community driven project that is focused on cross-chain interoperability.
Celer is a multi-chain operating system. Through Celer IM, developers can build inter-chain dApps using the Celer Inter-chain Message SDK with efficient liquidity utilization, coherent application logic, and shared states across multiple blockchains. Users of Celer-enabled dApps will enjoy the benefits of a diverse multi-blockchain ecosystem with the simplicity of a single-transaction UX from a single chain. Ultimately, the goal is to have developers using the existing Celer technology to abstract the concept of “multiple blockchain” away.
We believe Celer community has one of the best developer support processes through our strong network of community developers.
Finally, we thank Uniswap governance bodies for considering our submission to the RFP and we are also happy to discuss any other collaboration here.
Other Resources on Celer:
yep prob not the right place. the transactions I think you're referring to are expected behavior. I responded in DM.
yep prob not the right place. the transactions I think you're referring to are expected behavior. I responded in DM.
Authors Laura Lotti & Toby Shorin, Other Internet
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:
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.
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.
Additionally, optimistic interoperability arguably introduces one more attack vector:
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.
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:
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.
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
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
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.
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:
Hi all, I want to say a couple things on how we'll move forward. First of all, we've taken a deep look at, and are evaluating, the most credible bridge providers in the space. Thank you to Mo, Hendrik, and Primo for sending your proposals. After these three, we are not soliciting any additional proposals at this time.
Jeff, want to respond directly to your concerns. I believe we share the goal of ensuring the best possible outcome for the protocol. As a delegate and champion of Uniswap governance, we have taken the initiative to start this important project and will continue to facilitate it in a way that is respectful of the time of everyone involved. We opened our invitation to bridge projects two months ago, and there has been ample time for both introductions and for bridge providers to reach out and post proposals. In light of the late proposals, we have also extended our timeline an additional week to evaluate these vendors more closely.
Hi all, I want to say a couple things on how we'll move forward. First of all, we've taken a deep look at, and are evaluating, the most credible bridge providers in the space. Thank you to Mo, Hendrik, and Primo for sending your proposals. After these three, we are not soliciting any additional proposals at this time.
Jeff, want to respond directly to your concerns. I believe we share the goal of ensuring the best possible outcome for the protocol. As a delegate and champion of Uniswap governance, we have taken the initiative to start this important project and will continue to facilitate it in a way that is respectful of the time of everyone involved. We opened our invitation to bridge projects two months ago, and there has been ample time for both introductions and for bridge providers to reach out and post proposals. In light of the late proposals, we have also extended our timeline an additional week to evaluate these vendors more closely.
As one of the few Uniswap governance actors with no vested interests in any of the projects involved, we are able to act in the sole interest of the protocol. Our position as an neutral third party has additionally given us the ability to negotiate directly with vendors and ensure that Uniswap Protocol receives a high level of support.
Our mandate as a UGP grant recipient is to perform governance initiatives for the Uniswap protocol, and we will continue to carry out our responsibilities. We have worked closely with fellow delegates and third party technical experts to create a clear set of evaluation criteria, and we aim to deliver a recommendation to the community on the best bridge to move forward with. To clarify, we are not just picking a provider without input. As @eek637 helpfully clarified above, we are making a recommendation that community members and delegates will have the opportunity to express an opinion on through a vote.
Obviously, the reason why we’ve been taking our time with our assessment and feedback is precisely the dire need for careful evaluation of all the available options, both from a theoretical model-based and a practical implementation-wise standpoint. Before reaching our informed opinion, we consulted with the bridge teams, conducting interviews with them, and asking for clarifications on many aspects of their design, implementation, and future roadmap choices. In this way, we believe we are fit to weigh in with our feedback for the protocols, and our view on what might best serve Uniswap’s diverse set of needs.
TL;DR: Having universal validators, and not specific to the community served by the bridge provider, is not a good idea for a protocol with as large TVL as Uniswap. On the other hand, optimistic solutions with "fraud proof" designs are riddled with largely ad-hoc "optimistic intervals" which are at the danger of being violated at periods of high gas demand when provers might be priced out of the opportunity to prove fraud, and arbitrary "Watcher griefing" disconnecting communication channels could pose large issues when Watchers are allowed to be fully decentralized (as they should), i.e., everyone (this has been proposed to be mitigated through economic incentives, but with an unclear and unspecified mechanism at work). We propose a synergy between Axelar and 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).
Obviously, the reason why we’ve been taking our time with our assessment and feedback is precisely the dire need for careful evaluation of all the available options, both from a theoretical model-based and a practical implementation-wise standpoint. Before reaching our informed opinion, we consulted with the bridge teams, conducting interviews with them, and asking for clarifications on many aspects of their design, implementation, and future roadmap choices. In this way, we believe we are fit to weigh in with our feedback for the protocols, and our view on what might best serve Uniswap’s diverse set of needs.
TL;DR: Having universal validators, and not specific to the community served by the bridge provider, is not a good idea for a protocol with as large TVL as Uniswap. On the other hand, optimistic solutions with "fraud proof" designs are riddled with largely ad-hoc "optimistic intervals" which are at the danger of being violated at periods of high gas demand when provers might be priced out of the opportunity to prove fraud, and arbitrary "Watcher griefing" disconnecting communication channels could pose large issues when Watchers are allowed to be fully decentralized (as they should), i.e., everyone (this has been proposed to be mitigated through economic incentives, but with an unclear and unspecified mechanism at work). We propose a synergy between Axelar and 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).
Before we report on our feedback and assessment, it is crucial to highlight that how the concept of "cross-chain governance" will evolve over time may vitally affect our present choice (thanks to Steven Yin for his contributions to the whole discussion). Currently, cross-chain governance is understood as "reflecting the governance decisions on Ethereum on all the other chains". One possible future is where the voting process itself can be distributed among different chains. This will inevitably require some concept of governance tokens to exist across chains. There are at least two possible approaches to this: 1. bridging existing governance tokens from Ethereum to other chains using a generic bridge, or 2. Creating native governance tokens on each chain. The second approach will require Uniswap to implement its own logic for managing the burn and minting of UNI tokens on different chains, and use a generic message-passing layer to relay the messages. The first approach relegates the control of the minting/burning process to the bridge provider. Since existing bridge providers have more experience with this process, being audited several times, their smart contract code is likely to be more secure than the second approach. Note that the risk of having smart contract vulnerabilities is high, judging from the frequencies of bridge hacks, and the significant TVL of Uniswap. However, there are two downsides to the first approach: a) Uniswap has less control over the token creation/burning process (thus harder to create custom logic in the future), and b) It is harder to migrate to a different setup, essentially enhancing the degree of vendor lock-in that should already be a parameter in our bridge selection thought process, even without expanded cross-chain governance. The aforementioned points are worth considering and deliberating upon, because the present choice will necessarily directly affect the ease (or hardness) of this potential future ability to expand.
Now that we've clarified the cross-chain messaging aspect and weighed in on how the current choice might affect future capabilities, before choosing a bridge provider and/or the technology behind it ---which is, in our view, the most important aspect of this decision, as also delineated by Other Internet, in their thought process--- we should keep in mind that Uniswap has a massive TVL, which significantly affects the economic incentives that are ingrained (directly or indirectly) in the bridging mechanism.
Implementation-wise, we believe that there is an important gap that needs to be addressed in order for any of the current bridge providers to be adopted into a fully-fledged cross-chain Uniswap governance parameter update mechanism. It is not clear to us which organization is the one that should assist with this; should this be the bridge provider itself, as implied by Other Internet's RFC? There's benefits for and arguments against both; in short, requiring the bridge provider to perform a significant part of this development could draw from critical resources that sustain the security and other features of the bridge: this might not be fair (for bridge providers whose methodologies are still in various phases of development, with meritorious models but not mainnet implementation-ready) or efficient. On the other hand, if someone outside of the bridge provider is tasked with this, it would be expected that there should be some kind of offer solicitation for this specific task, along with auditing of the final solution. As mentioned in the post above, this is where it is most beneficial for a potential legal agreement to kick in, and we will leave it up to further discussion from the community.
For our model-based analysis, which we believe to be the rather significant part of the feedback we give (given that no solution is requested to be "plug-and-play"; c.f., Implementation above, and there has been already Other Internet's analysis of funding, reputability, and audits for the various protocols), we will begin with a general principle which we deem crucial not to be violated: Stakeholders should participate in the validator set, to make sure that the incentives are correctly aligned. Another way to make sure that this could happen is, as Other Internet suggested, to have an optimistic solution, where again every stakeholder of the community would potentially be able to provide fraud claims, shall a malicious message be found in the network. Nevertheless, the issues with the optimistic window length, along with the possibility of censoring, make this, in our view, an inferior solution to providing a solid validator-based approach.
We begin with LayerZero, which we deem to be a generic message-passing framework. Their model is all-powerful, allowing the specification of custom Oracle/Relayer combinations for each protocol by themselves (or adopt the default configuration, which then becomes a central validator set). For the reasons delineated above, the default configuration should be ruled out for protocols with massive TVL, i.e., Uniswap. The custom configuration with the ability to have major UNI holders acting as a collective Oracle in a custom-designed system would be our proposal. However, this maximum configurability in terms of message validation specifics (which includes choosing the setup of an oracle-relayer system at a protocol-specific level), security parameters, and utilized libraries of the ecosystem, comes potentially at the expense of ease of use and out-of-the-box setup (again, only given the custom desired configuration). This configurability, of course, has immense advantage on security guarantees in separating different risk entities (participating protocols in the cross-chain communication system), in case of corruption/malice of some validating entity/ies. Similar guarantees can be achieved via including an appropriately diverse set of validating entities (see Generic Principle above). As noticed, though, we believe that the complexity of an appropriate design to achieve the guarantees evidenced above may not be within the current scope of Uniswap’s abilities.
We continue with Wormhole, which has a large team due to Jump and as a result, has implemented, staged for production, and is actively developing a wide variety of features with robust guarantees. There is a central set of 19 validators, which is a significantly large value contributing to decentralization compared to other central-validator-based bridges. One of the core trust assumptions of Wormhole’s model is the attributability of the message attestations of Guardians by means of their signatures in the (currently multi-sig) scheme. Due to this characteristic, the Guardians have their reputation as well as ownership of protocol shares at stake. Without this attributability, further research is definitely needed to correctly incentivize participants. There is also a governance-controlled per-message fee, whose change is unpredictable in unforeseen circumstances, and whose interplay with potential cross-chain vendor lock-in needs to be taken into account. In summary, we think that Wormhole is the most implementation-ready out of many providers we examined, but in terms of the model, it isn't there just yet (because of adjustments before its model passes our checks and balances). We would suggest that they add various customizable per-application aspects to lower the systemic risk, and in particular add the ability for a protocol to have a Custom Guardian Set.
For Nomad, and in general optimistic-based solution approaches (we will not deal here with the necessarily dire implications of the recent hack but only examine the general model), we believe they are clearly surpassed by appropriate validator-based PoS systems, by virtue of their safety guarantees. Here, we disagree with Other Internet that the optimistic model has better security/safety guarantees than the latter. Such a statement would generally hold for a Layer-1/2 on the same chain implementing fraud proofs that can be verified in an austere way (absolutely verifiable by virtue of only on-current-chain elements). Let's delve into some definitions to further analyze that: the term "optimism" generally confounds two different desiderata which shouldn't be confounded: 1. vanilla optimism would be that "transactions are always considered valid, unless otherwise indicated," and 2. the "otherwise indicated", i.e., when a fraud proof is furnished, means that the fraud proof needs to be an actually true proof (i.e., verifiable by an honest observer who can prove this only on one chain) of the fact that the signed transaction doesn't correspond to the current state of the (other) chain. However, critically, Nomad's Watchers can arbitrarily decide to "grief", closing the communication channel, and the 2nd part of the above desiderata is not being fulfilled (there has been a proposal by Nomad team contributors to integrate economic incentives in order to override that, but to this day, no specific mechanisms which would need to also be analyzed). There is certainly interesting research to improve upon this (sadly, research shows this might end up being very chain-consensus-specific), but the practical system currently implemented doesn't satisfy the generic claim that same-chain optimistic mechanisms (e.g., L2s) enjoy.
For Abacus, we believe that the idea of application-specific sovereign consensus is a very good idea matching our General Principle above. In accordance to this, sovereign consensus would necessarily be utilized by Uniswap's implementation, and the protocol would be able to combine the benefits of both a default setup with trusted nodes (the 4/5 configuration, e.g.) along with a custom setup of UNI stakeholders as a custom validator set. This application-specific set makes sure that the future of the Uniswap ecosystem is safeguarded from actors which could turn potentially malicious or adversely affected by central decisions (systemic risk). Our suggestion for what we would like to see in this protocol before we say that its model is theoretically robust is to integrate potential weighting of the custom validators in the custom validator set for sovereign consensus in an efficient way, as well as allow to easily change the custom validator set dynamically in real-time. Because we believe that this is served 100% by adding a PoS permissionless system for the custom validators, we continue this below inside our Axelar analysis.
For Axelar, which is the only true permissionless validator-set system, we think that the PoS consensus system to verify any message is truly the state-of-the-art, subject to the General Principle above, i.e., that the stakeholders of an ecosystem with large TVL would participate in this PoS scheme. When this happens, then the system would effectively engage the underlying stakeholders (if needed; if not, then the default PoS participants can provide the consensus), who have no economic incentive to override and lie about their own decisions. What we are lacking currently from this system, and we highly suggest to the team that it be integrated, is application-specificity tightly integrated with default characteristics, akin to the Abacus ones: applications (certainly Uniswap) should be able to, if needed, provide a supermajority of actual protocol governance stakeholders as the consensus mechanism; but under normal conditions, a supermajority of the normal PoS scheme might suffice. We can see the helpfulness of a default configuration with a truly permissionless system of validators (as is currently guaranteed by the AXL token) towards smaller protocols bootstrapping their cross-chain messaging, but also recognize that this default alone might be somewhat inadequate for a protocol with massive TVL at stake.
Lastly, a generic comment on gas costs/efficiency: since the Uniswap community is currently intending to use cross-chain community solely for message-passing the parameter updates (see paragraph on what cross-chain governance means above), it is not necessary to wait for the adoption of either threshold signature schemes or more sophisticated zero-knowledge proofs. While altogether it’s not clear whether zk would provide any benefit whatsoever (in fact, in some of the threat models above, according to our theoretical analysis, zk would even constitute a violation of certain trust assumptions, and might misincentivize validating entities), gas efficiency might be more desirable shall the Uniswap community decide to move on to voting governance proposals on-chain in a multi-chain environment.
We are definitely looking forward to seeing more open discussion in the community!
Blockchain@Columbia believes that there should be more open discussion on this very important matter, and to this end, we wanted to offer some of our thoughts formed in conjunction with our Uniswap Protocol Lead @jason_of_cs, first on the process front, and as a response to Other Internet’s commentary on it:
To the need for setting the DAO priorities as per providing a “strategic direction setting” for the protocol, our counterargument is that there is no need to curtail or otherwise limit or affect the DAO process, other than proper commentary on the governance forum. If the community deems a proposal serious and interesting enough to initiate vivid discussions on the forum and to merit voting, then we believe that it should be granted the right to be properly considered to its fullest extent, irrespective of any “strategic directions”. In particular, to the example of Ichi’s stablecoin proposals, it would suffice to make note of the facts asserted in Other Internet’s assessment on the governance forum, and let the community decide on the merits and drawbacks of the proposal.
Blockchain@Columbia believes that there should be more open discussion on this very important matter, and to this end, we wanted to offer some of our thoughts formed in conjunction with our Uniswap Protocol Lead @jason_of_cs, first on the process front, and as a response to Other Internet’s commentary on it:
To the need for setting the DAO priorities as per providing a “strategic direction setting” for the protocol, our counterargument is that there is no need to curtail or otherwise limit or affect the DAO process, other than proper commentary on the governance forum. If the community deems a proposal serious and interesting enough to initiate vivid discussions on the forum and to merit voting, then we believe that it should be granted the right to be properly considered to its fullest extent, irrespective of any “strategic directions”. In particular, to the example of Ichi’s stablecoin proposals, it would suffice to make note of the facts asserted in Other Internet’s assessment on the governance forum, and let the community decide on the merits and drawbacks of the proposal.
On the issue at hand, which is the process for the procurement of a bridge provider, we agree with Other Internet’s proposal that it would be beneficial for a legal agreement to be reached with the bridge team, so as to better guarantee the quality of the outcome, especially when considering the value of the totality of the Uniswap community. However, we believe that their judgment of the Osmosis paradigm for their selection of a bridge partner was somewhat unfair: Other Internet advocates for a more centrally-driven governance model than we believe is essential, where an informed organization makes a strong recommendation and ultimately in a large degree decides the outcome. We believe that this would constitute an overreach for the DAO’s authority over the protocol, and we call for more openness than the current (and proposed) reticent approach. For the bridge election procedure, we propose that a method similar to Osmosis be utilized to select Uniswap’s bridge provider: experts and informed organizations should seek to engage with the various bridge teams, concisely write down their thoughts on advantages and disadvantages of each of them for our community, engage in an open discussion over the forum, and then let the DAO decide on the full spectrum of available options (with ranked voting, if this is possible in Uniswap Governance). We thus voice our disagreement with and concern for Other Internet’s proposed experiment of a procurement process. We would gladly welcome further open discussion on this crucial issue.
Primo, Hendrik, Mo:
Thank you for these thorough proposals. Please note that you are 2 months past when we requested bridge providers reach out with proposals, per our original forum post. In the intervening period, we’ve obtained other highly competitive proposals, and have conducted an extensive analysis we’re preparing to post.
Primo, Hendrik, Mo:
Thank you for these thorough proposals. Please note that you are 2 months past when we requested bridge providers reach out with proposals, per our original forum post. In the intervening period, we’ve obtained other highly competitive proposals, and have conducted an extensive analysis we’re preparing to post.
Of course, security for Uniswap governance is paramount, and we want to ensure that we are taking all options into consideration. For this reason, we’ve decided that we will conduct a 1-week review to compare your offers to the other proposals we’ve received. We’ll post a followup on the forum next week.
Hi all, I'm providing a brief update on where we are with the UGM. As outlined in the original post, we we currently in the process of soliciting formal proposals from multiple bridge technology providers. Once we've collected all of them, we'll post the proposals here with a clear comparison, our analysis and recommendation of a bridge provider, and next steps.
Thanks for this thoughtful RFC. This is a heady issue, and our opinion at AGF is that is valuable to have one party serving as the fact finders and filter through which we can evaluate potential service providers. There's still lots of room for community involvement; if anyone has particular technical concerns that a potential provider should answer, they can and certainly should speak up here or reach out to Other Internet.
I anticipate more forum participation after the next post where a comparison table and recommendation has been presented. Given that this is a highly technical RFQ that is sort of defining a category of service in flight, concrete examples of what will be provided and the benefits that will be conferred will be useful for those of us who are wrapping our heads around what the implications of this engagement might be.
Authors Laura Lotti & Toby Shorin, Other Internet
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:
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.
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.
Additionally, optimistic interoperability arguably introduces one more attack vector:
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.
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:
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.
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
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
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.
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:
Hi all, I want to say a couple things on how we'll move forward. First of all, we've taken a deep look at, and are evaluating, the most credible bridge providers in the space. Thank you to Mo, Hendrik, and Primo for sending your proposals. After these three, we are not soliciting any additional proposals at this time.
Jeff, want to respond directly to your concerns. I believe we share the goal of ensuring the best possible outcome for the protocol. As a delegate and champion of Uniswap governance, we have taken the initiative to start this important project and will continue to facilitate it in a way that is respectful of the time of everyone involved. We opened our invitation to bridge projects two months ago, and there has been ample time for both introductions and for bridge providers to reach out and post proposals. In light of the late proposals, we have also extended our timeline an additional week to evaluate these vendors more closely.
Hi all, I want to say a couple things on how we'll move forward. First of all, we've taken a deep look at, and are evaluating, the most credible bridge providers in the space. Thank you to Mo, Hendrik, and Primo for sending your proposals. After these three, we are not soliciting any additional proposals at this time.
Jeff, want to respond directly to your concerns. I believe we share the goal of ensuring the best possible outcome for the protocol. As a delegate and champion of Uniswap governance, we have taken the initiative to start this important project and will continue to facilitate it in a way that is respectful of the time of everyone involved. We opened our invitation to bridge projects two months ago, and there has been ample time for both introductions and for bridge providers to reach out and post proposals. In light of the late proposals, we have also extended our timeline an additional week to evaluate these vendors more closely.
As one of the few Uniswap governance actors with no vested interests in any of the projects involved, we are able to act in the sole interest of the protocol. Our position as an neutral third party has additionally given us the ability to negotiate directly with vendors and ensure that Uniswap Protocol receives a high level of support.
Our mandate as a UGP grant recipient is to perform governance initiatives for the Uniswap protocol, and we will continue to carry out our responsibilities. We have worked closely with fellow delegates and third party technical experts to create a clear set of evaluation criteria, and we aim to deliver a recommendation to the community on the best bridge to move forward with. To clarify, we are not just picking a provider without input. As @eek637 helpfully clarified above, we are making a recommendation that community members and delegates will have the opportunity to express an opinion on through a vote.
Obviously, the reason why we’ve been taking our time with our assessment and feedback is precisely the dire need for careful evaluation of all the available options, both from a theoretical model-based and a practical implementation-wise standpoint. Before reaching our informed opinion, we consulted with the bridge teams, conducting interviews with them, and asking for clarifications on many aspects of their design, implementation, and future roadmap choices. In this way, we believe we are fit to weigh in with our feedback for the protocols, and our view on what might best serve Uniswap’s diverse set of needs.
TL;DR: Having universal validators, and not specific to the community served by the bridge provider, is not a good idea for a protocol with as large TVL as Uniswap. On the other hand, optimistic solutions with "fraud proof" designs are riddled with largely ad-hoc "optimistic intervals" which are at the danger of being violated at periods of high gas demand when provers might be priced out of the opportunity to prove fraud, and arbitrary "Watcher griefing" disconnecting communication channels could pose large issues when Watchers are allowed to be fully decentralized (as they should), i.e., everyone (this has been proposed to be mitigated through economic incentives, but with an unclear and unspecified mechanism at work). We propose a synergy between Axelar and 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).
Obviously, the reason why we’ve been taking our time with our assessment and feedback is precisely the dire need for careful evaluation of all the available options, both from a theoretical model-based and a practical implementation-wise standpoint. Before reaching our informed opinion, we consulted with the bridge teams, conducting interviews with them, and asking for clarifications on many aspects of their design, implementation, and future roadmap choices. In this way, we believe we are fit to weigh in with our feedback for the protocols, and our view on what might best serve Uniswap’s diverse set of needs.
TL;DR: Having universal validators, and not specific to the community served by the bridge provider, is not a good idea for a protocol with as large TVL as Uniswap. On the other hand, optimistic solutions with "fraud proof" designs are riddled with largely ad-hoc "optimistic intervals" which are at the danger of being violated at periods of high gas demand when provers might be priced out of the opportunity to prove fraud, and arbitrary "Watcher griefing" disconnecting communication channels could pose large issues when Watchers are allowed to be fully decentralized (as they should), i.e., everyone (this has been proposed to be mitigated through economic incentives, but with an unclear and unspecified mechanism at work). We propose a synergy between Axelar and 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).
Before we report on our feedback and assessment, it is crucial to highlight that how the concept of "cross-chain governance" will evolve over time may vitally affect our present choice (thanks to Steven Yin for his contributions to the whole discussion). Currently, cross-chain governance is understood as "reflecting the governance decisions on Ethereum on all the other chains". One possible future is where the voting process itself can be distributed among different chains. This will inevitably require some concept of governance tokens to exist across chains. There are at least two possible approaches to this: 1. bridging existing governance tokens from Ethereum to other chains using a generic bridge, or 2. Creating native governance tokens on each chain. The second approach will require Uniswap to implement its own logic for managing the burn and minting of UNI tokens on different chains, and use a generic message-passing layer to relay the messages. The first approach relegates the control of the minting/burning process to the bridge provider. Since existing bridge providers have more experience with this process, being audited several times, their smart contract code is likely to be more secure than the second approach. Note that the risk of having smart contract vulnerabilities is high, judging from the frequencies of bridge hacks, and the significant TVL of Uniswap. However, there are two downsides to the first approach: a) Uniswap has less control over the token creation/burning process (thus harder to create custom logic in the future), and b) It is harder to migrate to a different setup, essentially enhancing the degree of vendor lock-in that should already be a parameter in our bridge selection thought process, even without expanded cross-chain governance. The aforementioned points are worth considering and deliberating upon, because the present choice will necessarily directly affect the ease (or hardness) of this potential future ability to expand.
Now that we've clarified the cross-chain messaging aspect and weighed in on how the current choice might affect future capabilities, before choosing a bridge provider and/or the technology behind it ---which is, in our view, the most important aspect of this decision, as also delineated by Other Internet, in their thought process--- we should keep in mind that Uniswap has a massive TVL, which significantly affects the economic incentives that are ingrained (directly or indirectly) in the bridging mechanism.
Implementation-wise, we believe that there is an important gap that needs to be addressed in order for any of the current bridge providers to be adopted into a fully-fledged cross-chain Uniswap governance parameter update mechanism. It is not clear to us which organization is the one that should assist with this; should this be the bridge provider itself, as implied by Other Internet's RFC? There's benefits for and arguments against both; in short, requiring the bridge provider to perform a significant part of this development could draw from critical resources that sustain the security and other features of the bridge: this might not be fair (for bridge providers whose methodologies are still in various phases of development, with meritorious models but not mainnet implementation-ready) or efficient. On the other hand, if someone outside of the bridge provider is tasked with this, it would be expected that there should be some kind of offer solicitation for this specific task, along with auditing of the final solution. As mentioned in the post above, this is where it is most beneficial for a potential legal agreement to kick in, and we will leave it up to further discussion from the community.
For our model-based analysis, which we believe to be the rather significant part of the feedback we give (given that no solution is requested to be "plug-and-play"; c.f., Implementation above, and there has been already Other Internet's analysis of funding, reputability, and audits for the various protocols), we will begin with a general principle which we deem crucial not to be violated: Stakeholders should participate in the validator set, to make sure that the incentives are correctly aligned. Another way to make sure that this could happen is, as Other Internet suggested, to have an optimistic solution, where again every stakeholder of the community would potentially be able to provide fraud claims, shall a malicious message be found in the network. Nevertheless, the issues with the optimistic window length, along with the possibility of censoring, make this, in our view, an inferior solution to providing a solid validator-based approach.
We begin with LayerZero, which we deem to be a generic message-passing framework. Their model is all-powerful, allowing the specification of custom Oracle/Relayer combinations for each protocol by themselves (or adopt the default configuration, which then becomes a central validator set). For the reasons delineated above, the default configuration should be ruled out for protocols with massive TVL, i.e., Uniswap. The custom configuration with the ability to have major UNI holders acting as a collective Oracle in a custom-designed system would be our proposal. However, this maximum configurability in terms of message validation specifics (which includes choosing the setup of an oracle-relayer system at a protocol-specific level), security parameters, and utilized libraries of the ecosystem, comes potentially at the expense of ease of use and out-of-the-box setup (again, only given the custom desired configuration). This configurability, of course, has immense advantage on security guarantees in separating different risk entities (participating protocols in the cross-chain communication system), in case of corruption/malice of some validating entity/ies. Similar guarantees can be achieved via including an appropriately diverse set of validating entities (see Generic Principle above). As noticed, though, we believe that the complexity of an appropriate design to achieve the guarantees evidenced above may not be within the current scope of Uniswap’s abilities.
We continue with Wormhole, which has a large team due to Jump and as a result, has implemented, staged for production, and is actively developing a wide variety of features with robust guarantees. There is a central set of 19 validators, which is a significantly large value contributing to decentralization compared to other central-validator-based bridges. One of the core trust assumptions of Wormhole’s model is the attributability of the message attestations of Guardians by means of their signatures in the (currently multi-sig) scheme. Due to this characteristic, the Guardians have their reputation as well as ownership of protocol shares at stake. Without this attributability, further research is definitely needed to correctly incentivize participants. There is also a governance-controlled per-message fee, whose change is unpredictable in unforeseen circumstances, and whose interplay with potential cross-chain vendor lock-in needs to be taken into account. In summary, we think that Wormhole is the most implementation-ready out of many providers we examined, but in terms of the model, it isn't there just yet (because of adjustments before its model passes our checks and balances). We would suggest that they add various customizable per-application aspects to lower the systemic risk, and in particular add the ability for a protocol to have a Custom Guardian Set.
For Nomad, and in general optimistic-based solution approaches (we will not deal here with the necessarily dire implications of the recent hack but only examine the general model), we believe they are clearly surpassed by appropriate validator-based PoS systems, by virtue of their safety guarantees. Here, we disagree with Other Internet that the optimistic model has better security/safety guarantees than the latter. Such a statement would generally hold for a Layer-1/2 on the same chain implementing fraud proofs that can be verified in an austere way (absolutely verifiable by virtue of only on-current-chain elements). Let's delve into some definitions to further analyze that: the term "optimism" generally confounds two different desiderata which shouldn't be confounded: 1. vanilla optimism would be that "transactions are always considered valid, unless otherwise indicated," and 2. the "otherwise indicated", i.e., when a fraud proof is furnished, means that the fraud proof needs to be an actually true proof (i.e., verifiable by an honest observer who can prove this only on one chain) of the fact that the signed transaction doesn't correspond to the current state of the (other) chain. However, critically, Nomad's Watchers can arbitrarily decide to "grief", closing the communication channel, and the 2nd part of the above desiderata is not being fulfilled (there has been a proposal by Nomad team contributors to integrate economic incentives in order to override that, but to this day, no specific mechanisms which would need to also be analyzed). There is certainly interesting research to improve upon this (sadly, research shows this might end up being very chain-consensus-specific), but the practical system currently implemented doesn't satisfy the generic claim that same-chain optimistic mechanisms (e.g., L2s) enjoy.
For Abacus, we believe that the idea of application-specific sovereign consensus is a very good idea matching our General Principle above. In accordance to this, sovereign consensus would necessarily be utilized by Uniswap's implementation, and the protocol would be able to combine the benefits of both a default setup with trusted nodes (the 4/5 configuration, e.g.) along with a custom setup of UNI stakeholders as a custom validator set. This application-specific set makes sure that the future of the Uniswap ecosystem is safeguarded from actors which could turn potentially malicious or adversely affected by central decisions (systemic risk). Our suggestion for what we would like to see in this protocol before we say that its model is theoretically robust is to integrate potential weighting of the custom validators in the custom validator set for sovereign consensus in an efficient way, as well as allow to easily change the custom validator set dynamically in real-time. Because we believe that this is served 100% by adding a PoS permissionless system for the custom validators, we continue this below inside our Axelar analysis.
For Axelar, which is the only true permissionless validator-set system, we think that the PoS consensus system to verify any message is truly the state-of-the-art, subject to the General Principle above, i.e., that the stakeholders of an ecosystem with large TVL would participate in this PoS scheme. When this happens, then the system would effectively engage the underlying stakeholders (if needed; if not, then the default PoS participants can provide the consensus), who have no economic incentive to override and lie about their own decisions. What we are lacking currently from this system, and we highly suggest to the team that it be integrated, is application-specificity tightly integrated with default characteristics, akin to the Abacus ones: applications (certainly Uniswap) should be able to, if needed, provide a supermajority of actual protocol governance stakeholders as the consensus mechanism; but under normal conditions, a supermajority of the normal PoS scheme might suffice. We can see the helpfulness of a default configuration with a truly permissionless system of validators (as is currently guaranteed by the AXL token) towards smaller protocols bootstrapping their cross-chain messaging, but also recognize that this default alone might be somewhat inadequate for a protocol with massive TVL at stake.
Lastly, a generic comment on gas costs/efficiency: since the Uniswap community is currently intending to use cross-chain community solely for message-passing the parameter updates (see paragraph on what cross-chain governance means above), it is not necessary to wait for the adoption of either threshold signature schemes or more sophisticated zero-knowledge proofs. While altogether it’s not clear whether zk would provide any benefit whatsoever (in fact, in some of the threat models above, according to our theoretical analysis, zk would even constitute a violation of certain trust assumptions, and might misincentivize validating entities), gas efficiency might be more desirable shall the Uniswap community decide to move on to voting governance proposals on-chain in a multi-chain environment.
We are definitely looking forward to seeing more open discussion in the community!
Blockchain@Columbia believes that there should be more open discussion on this very important matter, and to this end, we wanted to offer some of our thoughts formed in conjunction with our Uniswap Protocol Lead @jason_of_cs, first on the process front, and as a response to Other Internet’s commentary on it:
To the need for setting the DAO priorities as per providing a “strategic direction setting” for the protocol, our counterargument is that there is no need to curtail or otherwise limit or affect the DAO process, other than proper commentary on the governance forum. If the community deems a proposal serious and interesting enough to initiate vivid discussions on the forum and to merit voting, then we believe that it should be granted the right to be properly considered to its fullest extent, irrespective of any “strategic directions”. In particular, to the example of Ichi’s stablecoin proposals, it would suffice to make note of the facts asserted in Other Internet’s assessment on the governance forum, and let the community decide on the merits and drawbacks of the proposal.
Blockchain@Columbia believes that there should be more open discussion on this very important matter, and to this end, we wanted to offer some of our thoughts formed in conjunction with our Uniswap Protocol Lead @jason_of_cs, first on the process front, and as a response to Other Internet’s commentary on it:
To the need for setting the DAO priorities as per providing a “strategic direction setting” for the protocol, our counterargument is that there is no need to curtail or otherwise limit or affect the DAO process, other than proper commentary on the governance forum. If the community deems a proposal serious and interesting enough to initiate vivid discussions on the forum and to merit voting, then we believe that it should be granted the right to be properly considered to its fullest extent, irrespective of any “strategic directions”. In particular, to the example of Ichi’s stablecoin proposals, it would suffice to make note of the facts asserted in Other Internet’s assessment on the governance forum, and let the community decide on the merits and drawbacks of the proposal.
On the issue at hand, which is the process for the procurement of a bridge provider, we agree with Other Internet’s proposal that it would be beneficial for a legal agreement to be reached with the bridge team, so as to better guarantee the quality of the outcome, especially when considering the value of the totality of the Uniswap community. However, we believe that their judgment of the Osmosis paradigm for their selection of a bridge partner was somewhat unfair: Other Internet advocates for a more centrally-driven governance model than we believe is essential, where an informed organization makes a strong recommendation and ultimately in a large degree decides the outcome. We believe that this would constitute an overreach for the DAO’s authority over the protocol, and we call for more openness than the current (and proposed) reticent approach. For the bridge election procedure, we propose that a method similar to Osmosis be utilized to select Uniswap’s bridge provider: experts and informed organizations should seek to engage with the various bridge teams, concisely write down their thoughts on advantages and disadvantages of each of them for our community, engage in an open discussion over the forum, and then let the DAO decide on the full spectrum of available options (with ranked voting, if this is possible in Uniswap Governance). We thus voice our disagreement with and concern for Other Internet’s proposed experiment of a procurement process. We would gladly welcome further open discussion on this crucial issue.
Primo, Hendrik, Mo:
Thank you for these thorough proposals. Please note that you are 2 months past when we requested bridge providers reach out with proposals, per our original forum post. In the intervening period, we’ve obtained other highly competitive proposals, and have conducted an extensive analysis we’re preparing to post.
Primo, Hendrik, Mo:
Thank you for these thorough proposals. Please note that you are 2 months past when we requested bridge providers reach out with proposals, per our original forum post. In the intervening period, we’ve obtained other highly competitive proposals, and have conducted an extensive analysis we’re preparing to post.
Of course, security for Uniswap governance is paramount, and we want to ensure that we are taking all options into consideration. For this reason, we’ve decided that we will conduct a 1-week review to compare your offers to the other proposals we’ve received. We’ll post a followup on the forum next week.
Hi all, I'm providing a brief update on where we are with the UGM. As outlined in the original post, we we currently in the process of soliciting formal proposals from multiple bridge technology providers. Once we've collected all of them, we'll post the proposals here with a clear comparison, our analysis and recommendation of a bridge provider, and next steps.
Thanks for this thoughtful RFC. This is a heady issue, and our opinion at AGF is that is valuable to have one party serving as the fact finders and filter through which we can evaluate potential service providers. There's still lots of room for community involvement; if anyone has particular technical concerns that a potential provider should answer, they can and certainly should speak up here or reach out to Other Internet.
I anticipate more forum participation after the next post where a comparison table and recommendation has been presented. Given that this is a highly technical RFQ that is sort of defining a category of service in flight, concrete examples of what will be provided and the benefits that will be conferred will be useful for those of us who are wrapping our heads around what the implications of this engagement might be.
Thanks for this thoughtful RFC. This is a heady issue, and our opinion at AGF is that is valuable to have one party serving as the fact finders and filter through which we can evaluate potential service providers. There's still lots of room for community involvement; if anyone has particular technical concerns that a potential provider should answer, they can and certainly should speak up here or reach out to Other Internet.
I anticipate more forum participation after the next post where a comparison table and recommendation has been presented. Given that this is a highly technical RFQ that is sort of defining a category of service in flight, concrete examples of what will be provided and the benefits that will be conferred will be useful for those of us who are wrapping our heads around what the implications of this engagement might be.
Ultimately, the community will express its view on whether Other Internet has recommended the right candidate by vote; if the vote is successful we've likely saved time and money for many stakeholders (and arguably candidates). If it is not, we have more information about what we're looking for in this vendor and can be more specific in our asks the next time around.
Thanks for this thoughtful RFC. This is a heady issue, and our opinion at AGF is that is valuable to have one party serving as the fact finders and filter through which we can evaluate potential service providers. There's still lots of room for community involvement; if anyone has particular technical concerns that a potential provider should answer, they can and certainly should speak up here or reach out to Other Internet.
I anticipate more forum participation after the next post where a comparison table and recommendation has been presented. Given that this is a highly technical RFQ that is sort of defining a category of service in flight, concrete examples of what will be provided and the benefits that will be conferred will be useful for those of us who are wrapping our heads around what the implications of this engagement might be.
Ultimately, the community will express its view on whether Other Internet has recommended the right candidate by vote; if the vote is successful we've likely saved time and money for many stakeholders (and arguably candidates). If it is not, we have more information about what we're looking for in this vendor and can be more specific in our asks the next time around.