[RFC - Update] Deploy Uniswap v3 (1 / 0.3 / 0.05 / 0.01) on BNB Chain (Binance)

[ilia_0x]

0xPlasma Labs and I have been big supporters and contributors to Uniswap ecosystem developments since v1 and all L1 and L2 blockchain ecosystems. Today I would like to raise a very important question that does not leave my thoughts and hear every person’s opinion from the community.

The Uniswap ecosystem is crucial in developing the global decentralized finance (DeFi) ecosystem. However, it has not yet deployed its protocol to the second-largest blockchain infrastructure by volume and user base, BNB Chain. This represents a missed opportunity for Uniswap to expand its reach and potentially drive further growth and adoption of DeFi.

Proposal

This proposal will authorize 0xPlasma Labs to deploy the Uniswap v3 protocol to the BNB PoS Chain on behalf of the community.

We believe this is the right moment for Uniswap to deploy on BNB PoS Chain, for many reasons (one of them is License expiration).

Uniswap v3 current stats

Total Value Locked - $2.6B

Chain Breakdown
Ethereum - $2.37B
Polygon - $99.84M
Arbitrum - $84.9M
Optimism - $44.53M
Celo - $865.4K

Potential TVL + LP Fees from BNB Chain - 50% * $2.73B (PancakeSwap)

Uniswap v3 volume on Ethereum chain

Source: Dune

BNB Chain current stats

BNB Chain is a decentralized, public blockchain that operates using a proof-of-stake (PoS) consensus mechanism. It is designed to support the development and deployment of decentralized applications (dApps) and decentralized finance (DeFi) projects and is powered by the Binance Coin (BNB) token. BNB Chain is operated by Binance, a leading cryptocurrency exchange and blockchain technology company, but is open to participation and contributions from a global community of developers, users, and stakeholders.

PancakeSwap Stats

Source: PancakeSwap

ETH vs. BNB

Source: DeFiLlame

The Important reasons why Uniswap v3 should be deployed to BNB Chain as soon as possible

1. BNB Chain has a large and growing user base, providing a potential new market for Uniswap v3.

2. BNB Chain offers high transaction speeds and low fees, making it a suitable platform for Uniswap’s decentralized exchange services.

3. Deploying to BNB Chain could help Uniswap to tap into the growing popularity of DeFi in the Binance ecosystem.

4. BNB Chain offers unique features such as staking and cross-chain support that could enhance Uniswap v3’s functionality.

5. BNB Chain’s strong governance model and active community could provide valuable support and feedback for the development of Uniswap v3.

6. Binance, the company behind BNB Chain, has a strong track record of supporting and promoting high-quality projects, potentially providing valuable exposure for Uniswap v3.

7. Binance has a global presence and a strong brand, which could help increase awareness and adoption of Uniswap v3 among retail and institutional investors.

8. Binance offers a range of products and services that could be integrated with Uniswap v3, such as the Binance Smart Chain and Binance DEX.

9. Deploying to BNB Chain could provide opportunities for collaboration and partnerships with other projects on the Binance ecosystem.

10. BNB Chain strongly focuses on security and compliance, providing a safe and trusted environment for Uniswap v3 to operate.

11. BNB Chain has a robust ecosystem of dApps and DeFi projects, providing potential opportunities for collaboration and co-development.

12. BNB Chain’s support for on-chain governance could enable Uniswap v3 to adopt a more decentralized and community-driven development model.

13. BNB Chain’s support for decentralized autonomous organizations (DAOs) could enable Uniswap v3 to adopt a more decentralized and community-driven business model.

14. BNB Chain’s strong emphasis on community engagement and participation could provide valuable support and feedback for Uniswap v3.

15. BNB Chain’s commitment to regulatory compliance could provide valuable support for Uniswap v3 as it seeks to expand into new markets and jurisdictions.

16. BNB Chain’s support for tokenization and digital asset management could enable Uniswap v3 to offer new services and features for users.

17. BNB Chain’s a fast-developing ecosystem of decentralized finance dapps and assets.

Why BNB DeFi ecosystem needs Uniswap v3

• BNB Chain has a big DeFi development community that needs a more advanced DEX ecosystem to boost the general DeFi ecosystem development
• Bridge supports BNB Chain needs a better liquidity source with less slippage
• Assets need more reliable DEX infrastructure to provide their users with a better trading experience
• We need to educate all BNB community about what is real DeFi and yield using Uniswap v3 as a reference.

What can Uniswap Ecosystem get from BNB chain deployment?

• Additional $1B of TVL + huge trading volume + earned fees for LPs
• 1-2M new users + UNI holders
• Huge respect and appreciation from DeFi devs
• More adoption for Uniswap NFT Platform (as BNB chain has a weak infra for NFTs)

Financial Incentives for Liquidity

We can consider a launch of Liquidity Farming and Quadrat Protocol for Uniswap v3 on BNB Chain, to attract more liquidity and incentives from BNB protocols and users.

Security and Governance Bridge

0xPlasma Labs would like to propose using for the Governance cross-chain infrastructure one of the current ETH<>BNB Bridges: HyperLoop (0xPlasma), Layer Zero, Celer, Stargate.

HyperLoop Overview

HyperLoop is a generalized cross-chain message-passing protocol inspired by roll-ups. At a high level, the HyperLoop protocol works by utilizing a network of Executors to observe and attest to messages on a source chain and relay those attestations to a destination chain. “WatchTower” node can disconnect Executors from the HyperLoop protocol if fraudulent attestations have been detected, and utilize Executor stake to payout for transactions on the destination chain.

A general L1<>L2 and L1<>L1 communication HyperLoop bridge supports arbitrary message passing.

More info on the HyperLoop protocol security:

The HyperLoop bridge supports generalized message passing, asset bridge, and swap (using Uniswap v3 and HyperDEX routers) for all supported EVM and non-EVM chains.
Applications using HyperLoop are secured by a set of WatchTowers, responsible for detecting fraud in the network. Only one WatchTower needs to be honest for the application to be safe. Instead of a consensus type of bridge, HyperLoop utilizes the over-collateral lending nodes and on-chain whitelists for the Executors.

Bridge Executors can’t pass an incorrect message or change the content. Importantly, we’ll be building out additional safety functionality and monitoring off & on-chain activity.

Security is top of mind for 0xPlasma. We are currently working with tier-1 auditors for HyperLoop and specifically in the review process for the bridge code. Audits will be conducted before each major upgrade. Besides audits, we offer a substantial bug bounty program.

You can read more about HyperLoop Bridge&Swap protocol here.

We would also like to discuss with the Uniswap Community the pros and cons of different ETH<>BNB bridges.

0xPlasma Labs Contribution to Uniswap v3

• HyperDEX aggregator supports routing via Uniswap v3
• HyperLoop cross-chain swap&bridge based on Uniswap v3 liquidity
• Quadrat Protocol - active liquidity management for Uniswap v3 positions
• Multi-chain Portfolio Management on Plasma.Finance supports Uniswap v3 position NFTs

License Exemption

We are requesting an exemption via an Additional Use Grant (license change enacted via the ENS domain uniswap.eth) that would allow the 0xPlasma Labs to use the Licensed Work to deploy it on BNB Chain, a layer 1 EVM compatible blockchain, provided that the deployment is subject to Ethereum layer 1 Uniswap Protocol governance and control. Uniswap V3 will be deployed on BNB Chain by the 0xPlasma Labs through the “Deploy Uniswap V3 Script.” 0xPlasma Labs would be permitted to use subcontractors to do this work.

Timeline (5-7 weeks)

We anticipate deployment of the smart contracts on the BNB Chain to take a few weeks. Additionally, Uniswap Labs has noted that they will need to complete some front-end updates and add the BNB chain to the auto-router — this will take ~4 weeks and they are prepared to ramp up following Uniswap community approval of this governance proposal.

Governance at deployment will be facilitated by the messaging bridge HyperLoop (or using any other native bridge that we discussed with the Uniswap Community).

1. Discussion on Governance Forum / Twitter Space
2. Uniswap v3 + Governance Bridge Deployment on BNB Chain Testnet. Tests and Simulations.
3. Temperature Check
4. Governance Proposal
5. Uniswap v3 Deployment to BNB Chain mainnet
6. Subgraph Deployment
7. Uniswap UI integration

For the further Governance Process, you can delegate your votes to our address:
(0xPlasma.eth) 0xA559f6d6B5A5661E46dEc454751683294BB26B9E

Looking forward,
Ilia.eth 0xPlasma.eth

[itchigo]

This is a good one! To enable Quadrat Strategies to BNB via uniswap!

[ilia_0x]

Let’s schedule a community call on Discord and Twitter Space for Uni and BNB community?

[Lagoon]

That’s good idea! huge market potential

[GFXlabs]

While GFX Labs isn’t a BSC user, we agree that BSC has a significant number of funds and users, so it is worth considering a Uni v3 deployment to BSC.

DeFi Llama has the overall TVL of DeFi at $41B, of which $24B is on Ethereum. The second largest is BSC at $4.5B. Pancake Swap has $2.35B in TVL. Dune reports BSC as having 753k weekly users. Even if that is off by 90%, that is still a significant number of users Uniswap should be pursuing.

The top pairs on Pancake Swap by 7 day volume:

Pair	7 day volume	Liquidity
WBNB/BUSD	$122m	$160m
USDT/WBNB	$111m	$117m
TIME/USDT	$35m	$9m
USDT/BUSD	$21m	$94m
CAKE/WBNB	$16m	$189m
ETH/WBNB	$16m	$50m
BNX/BUSD	$15m	$18m
BTCB/WBNB	$10m	$41m
BTCB/BUSD	$10m	$50m
CAKE/BUSD	$8m	$14m

Uniswap v3 is positioned to compete significantly with Pancake Swap because their pools are Uniswap v2 which aren’t as capital efficient. For example, Quickswap’s market share on Polygon has almost been totally eroded since Uniswap v3 was deployed.

Overall, we think a deployment would make sense, but we will conduct more research and talk with other voters before formally supporting the proposal. Perhaps the protocol can target an on-chain vote in early January.

Relevant Dune dashboards:

• Ethereum vs Binance Smart Chain by beliefanx

• Ethereum vs Binance Smart Chain: Comparison by badgar

• Cross-chain Usage & Fee Comparison Benchmarks - Ethereum, Optimism, Arbitrum, Avalanche, BNB Chain, Polygon, Gnosis, Fantom by msilb7

• Messari: Polygon Uniswap by Messari

• PancakeSwap v2 Swap Metrics by hsc

• Polygon - Uniswap vs. Quickswap by wanxin

[ilia_0x]

Thank you for the information and feedback. What do you think we need to review and prepare regarding BNB<>Uni before we move to the temperature check stage?

[GFXlabs]

Based on the new governance process, we think you need to wait seven days, and then you can make the temperature check. The temperature check needs to reach 10m For votes to advance to an on-chain vote.

As for us, we’re going to research some options for the cross-chain governance piece and will follow up next week.

[ilia_0x]

DAILY ACTIVE USERS BY BLOCKCHAIN

1. BNB Chain
2. Ethereum
3. Polygon
4. Solana
5. Arbitrum
6. Fantom
7. Optimism
8. Avalanche
9. Starknet
10. MultiversX

[devinwalsh]

Thank you @ilia_0x for this post! The UF is in support of this proposal generally, and believe launching on BSC would be beneficial for the Uniswap ecosystem.

I do have a few questions I’d like to ask to benefit Uniswap delegates.

1. If your team would be managing the deployment, could you give a bit more background information on yourself and your team?

I have a few questions on the Hyperloop bridge as well, below.

2. When will Hyperloop be deployed - how much has it been tested?

3. Can you provide more detail on this comment "Bridge Executors can’t pass an incorrect message or change the content. Importantly, we’ll be building out additional safety functionality and monitoring off & on-chain activity. ". It sounds like due to the existence of WatchTowers, that it is possible for Executors to pass incorrect (or potentially malicious) messages. What are the conditions under which a malicious/incorrect message could be passed to the BSC deployment?

4. How many Executors and WatchTowers are there today, and who are they?

Thank you again for pushing this proposal forward. Again, we are in favor of a BSC deployment, but first think the community would benefit from more detail on the points above.

[AlexSmirnov]

Hi everyone, I’m Alex — co-founder of deBridge

Since BNB Chain doesn’t have any canonical/trust-minimized bridge, I’d like to suggest using deBridge as a secure solution to execute and relay any Uniswap governance decisions from Ethereum to BNB Chain.

deBridge Overview

deBridge is a secure cross-chain infrastructure enabling seamless interoperability between blockchains, powering transfers of any messages and liquidity with zero slippage and zero locked liquidity at risk.

A transaction through deBridge’s architecture passes through two key layers:

• Protocol Layer (on-chain) – a set of on-chain smart contracts deployed on all deBridge-supported chains. The parameters of the smart contracts, such as fees, chains, and list of validators, are managed by deBridge governance.

• Infrastructure Layer (off-chain) – nodes run by validators elected via deBridge’s governance. These validators also run full nodes on all the blockchains supported by deBridge.
  

  

According to the cross-chain Deployment Proposals Framework, here are answers to the Bridge Security questions in the context of deBridge:

Does the bridge support arbitrary message passing?

Yes, deBridge infrastructure supports any message transfers and has delivered 126,000+ messages since its launch in February 2022. Details of any cross-chain transfer through deBridge’s infrastructure can be accessed by anyone on deExplorer

Is the bridge secured by a trusted entity, by a multi sig, or by a protocol/set of incentivized nodes?

Validation of any cross-chain transactions goes down to social consensus around forks. That’s why canonical or trust-minimized bridges based on light or full clients are possible only between two blockchain ecosystems (normally L1 and L2) as if there is a fork in L1, then there is a fork in L2 and users can always pick which of the forks to use.

Non-canonical interoperability layers and bridges can’t be fully trustless by their nature, due to the need to have a validation layer that should at least determine which of the forks is valid and supported by the community, so it’s all a matter of how this validation layer is implemented.

Different protocols have different implementations, such as:

• Oracle and relayer model
• Optimistic approach
• Zk or Succinct proofs
• Set of validation nodes

deBridge validation layer uses a “delegated staking and slashing” with a set of validation nodes, optimizing for security and speed. All validators are elected by and work for deBridge governance. To be confirmed, a transaction must be signed by at least ⅔ of the validators, i.e., 8 out of 12. The validators are disincentivized to act maliciously as they bear financial risks through a delegated staking and slashing module.

deBridge plans to scale its validator set, increasing the threshold of signatures required for message validation, and thus enhancing the protocol’s overall security.

Thanks to off-chain validation, the validators don’t need to communicate with each other, thus their IP addresses are never exposed, increasing the overall security of the infrastructure.

Does the bridge leverage the security of the source chain (e.g. Ethereum L1) or destination chain, or is the security provided by another third-party entity?

As described in the previous paragraph, any bridges and interoperability layers (except canonical ones) have to rely on the validation layer. deBridge leverages professional infrastructure providers to validate cross-chain messages passing through deBridge protocol.

Is it possible for a fraudulent message to be passed to the destination chain? If so, are there any recall mechanisms?

In order to forge a message, ⅔ of deBridge validators would need to collude and each one would need to provide a signature of the malicious message identifier. deBridge validators are professional infrastructure providers that validate many other protocols and blockchains. All validators bear reputational and financial risks

What are the ramifications of fraud to the malicious actor?

The validators are disincentivized to act maliciously as they bear financial risks for their service as per the delegated staking and slashing module.

Has the bridge code been audited? By a third party? What attack vectors and vulnerabilities were identified, if any? Have the identified vulnerabilities been remedied?

Security has always been the top priority for our team. deBridge and its’ periphery modules have been audited 17 times by Halborn, Zokyo, Ackee Blockchain, and Neodyme. Additionally, deBridge offers a $200,000 bounty program on Immunefi. All the findings and remediations can be seen in the published security audit reports available in the public Github repository

Additional resources:
Documentation portal
Developers portal
deBridge explorer

deBridge team will be glad to facilitate the development and security audit of all smart contracts needed to relay and execute Uniswap governance decisions from Ethereum to BNB Chain. If deBridge is chosen as messaging provider, our team will cover costs for the security audit, performed by our long-term security partner Halborn

We welcome any questions about deBridge in the comments below

[ilia_0x]

Here is some background of the 0xPlasma Labs Team:

• 0xPlasma Labs was established in 2017
• The team of 15 highly professional Web3 devs
• Team has already built a lot of DeFi products and protocols:
  Plasma.Finance - multi-chain DeFi aggregator and portfolio management platform
  HyperDEX - DEX aggregator, supporting 8 EVM chains
  Bridge Aggregator - routing for the cross-chain transactions via popular bridges
  HyperLoop Bridge - cross-chain bridge and swap protocol for EVM-chains
  Quadrat - active liquidity management protocol for Uniswap v3 (4 chains support)
  Plasma Wallet - self-custodial mobile wallet for DeFi

0xPlasma Labs past commitments for Uniswap:

• Integration of Uniswap v2 (swap + LPs)
• limit order protocol for Uniswap v2
• supporting Uniswap v2 and v3 for HyperDEX aggregation
• active liquidity management protocol for Uniswap v3
• analytic tool for liquidity pools on Uniswap v2 and v3
• data indexing from Uniswap v2 and v3 for TradingView price charts

0xPlasma Labs current commitments:

• Deployment of Uniswap v3 protocol on popular EVM chains on behalf of the Uniswap community.

[ilia_0x]

0xPlasma Labs has already deployed and tested Uniswap v3 Protocol on BNB testnet.
You can find all contracts using BNB testnet explorer: https://testnet.bscscan.com/

Here is a deployment log:

Step 1 complete [
  {
    message: 'Contract UniswapV3Factory deployed',
    address: '0x36fc68cd9D7fbD5d1C8Fb2c5920696108ee870E9',
    hash: '0xfa5a826e1c97e8a5d0f0202678b5b2238af368f35e3891001dffbd2e7e66329c'
  }
]
Step 2 complete [
  {
    message: 'UniswapV3Factory added a new fee tier 1 bps with tick spacing 1',
    hash: '0xf16f757ef3121ff949812a370ebef3ca28a05c0f3f203fe97de1cc9c8cc18222'
  }
]
Step 3 complete [
  {
    message: 'Contract UniswapInterfaceMulticall deployed',
    address: '0x343F50D46A779aF57E4148396A53CFe4578aAc52',
    hash: '0xd44a4703d5b0d3b746990919838937f26647a05867d6c22e35f5518ee307085f'
  }
]
Step 4 complete [
  {
    message: 'Contract ProxyAdmin deployed',
    address: '0x186b19053d23C90C79E9E1651a1E3C6A9cEC182A',
    hash: '0x7435f897beb8eb1b8c74d122913baaeefe008c285568c364defe5f2b2353eba3'
  }
]
Step 5 complete [
  {
    message: 'Contract TickLens deployed',
    address: '0x6f7676394DfBE14983Add5D637572c5aaA3D3fec',
    hash: '0x0d579eba7fe99e3a8c3c47d36b0f0553244a02fce97da65f6e050b619514442b'
  }
]
Step 6 complete [
  {
    message: 'Library NFTDescriptor deployed',
    address: '0x6482212a7DBf4619FD3cb0c904b032C1Fa249052',
    hash: '0x937b093fc5b2f1e161167966bbd9fbe12c1a9382507eac1d9e1f1a2cb168ddb6'
  }
]
Step 7 complete [
  {
    message: 'Contract NonfungibleTokenPositionDescriptor deployed',
    address: '0x4b6aA5198362A6CBFd41952CCc751005C8E01A2B',
    hash: '0xd0ab37b493abb859d39d021eece18ca8dbbdb1e3e0b93e58193431fe86712130'
  }
]
Step 8 complete [
  {
    message: 'Contract TransparentUpgradeableProxy deployed',
    address: '0x3072c436626d66442ba17A6a2f4A35c7020691d1',
    hash: '0xb16d218559b11cf22a75fd63e09db4bc1b90a43374898f1ecd74d25321ac7039'
  }
]
Step 9 complete [
  {
    message: 'Contract NonfungiblePositionManager deployed',
    address: '0xF235795E939A2A6076E82B8434649f5BcF9B9637',
    hash: '0x7ce1d2286cfc6fb7602d3b4165dacfb8ffce2ce0eddc10843ecc4eb2d1c73e08'
  }
]
Step 10 complete [
  {
    message: 'Contract V3Migrator deployed',
    address: '0x0c2F7954138C4b4EBa07d4570F13Fd9ACF5125b0',
    hash: '0x45aa608893dbee97f7e1138b9e4a32271252135605f96c91775667b7176e804b'
  }
]
Step 11 complete [
  {
    message: 'UniswapV3Factory owned by 0xf41da34fe2839959013480AD81D982638840A6D6 already'
  }
]
Step 12 complete [
  {
    message: 'Contract UniswapV3Staker deployed',
    address: '0xAf589B83EDE930400c3Ff6D629cf1DA325dD2907',
    hash: '0xe205a92bcc4464c16aeae9154d4f2eeb61019a0512470861463a579d0db5793e'
  }
]
Step 13 complete [
  {
    message: 'Contract QuoterV2 deployed',
    address: '0x4db0186D8d9E424e8FcBf25c575087EBb08e0332',
    hash: '0x3243c301e760b26a8425fcf21a7b4a8d9e28019d3b8fcc5f0b978867b446602f'
  }
]
Step 14 complete [
  {
    message: 'Contract SwapRouter02 deployed',
    address: '0xdc1Ad7d941334CcbF3CAcd2ae667D54019395C9a',
    hash: '0x8e0eb57880da4f05216bd1b88a0f99ccf688d1f56c95ef34b46dcb37777473f7'
  }
]
Step 15 complete [
  {
    message: 'ProxyAdmin owned by 0xf41da34fe2839959013480AD81D982638840A6D6 already'
  }
]
Deployment succeeded

[devenmatthews]

Just wanted to quickly drop my thoughts on bridge providers for Uniswap v3 deployments.

This is a governance bridge, and the Uniswap treasury is held on L1, so the main risk is a malicious governance proposal pointing the fee switch to a malicious address. This would siphon off funds while L1 governance deploys a new proposal to turn off the fee switch and de activate compromised bridge.

zk, optimistic, and light client “conanical” bridges are what we should be shooting for.

Even then, I’m personally not fully convinced on Optimistic Fraud proofs but many in this community are. While I think while they aren’t ideal, this is an acceptable risk tolerance for the governance use case.

Network of Validator bridges are glorified multisigs and should have a high level of scrutiny applied to them.

cryptographic security >>> crypto-economic incentives

I don’t think Network of Validator bridges are inherently unacceptable for Uniswap, but it’s important to realize they come in all shapes and sizes. It is important to ask a lot of questions such as:

• Validator set size, and more importantly, who is running these validators
• Signing threshold; does any small combination of entities running validators meet this threshold
• Does required stake/slash make it significantly unprofitable to exploit bridge

I mostly worry that many networks may have a single entity managing a large set of the validators, and a single phishing email could compromise a large set of the signing keys.

Uniswap is not ready to adopt a single bridge provider (and therefore, in my opinion not ready to expand its cross-chain ventures beyond governance), and therefore this risk is only relevant to the governance problem. The above scrutiny on network of validator bridges are not specific to any of the providers mentioned in this thread- just want to make sure community analyzes risk appropriately.

[ilia_0x]

Thank you for participating in our conversation and for your feedback on the bridge topic of this proposal.

I believe the Uniswap community understands and evaluates the risks of cross-chain governance messaging using the current bridge infrastructure. As many chains, where Uniswap v3 will be deployed in 2023, don’t have a zk or optimistic bridges, we have to rely on other trusted providers of bridge infrastructure. That’s why I proposed a list of the potential bridges (deBridge, Celer, Stargate, Layer Zero) to proceed with the feather governance voting on a new chain.

Also, the bridge risk can only arise on subsequent votes regarding fees in the protocol, and potential financial risk can only be expressed in a maximum of a couple of hundred thousand dollars not earned by liquidity providers in a short period of time. Ultimately, this risk cannot affect the liquidity allocated in the protocol. And also this bridge risk is not affecting the initial protocol deployment for this proposal.

The initial Uniswap v3 protocol deployment to BNB chain (or to any other chain) will include all fee tiers (1, 0.3, 0.05, 0.01) so probably the governance won’t touch the protocol for the entire year or two. This period will be more than enough to explore the most trusted bridge infrastructure until the next on-chain proposal for Uniswap on BNB chain.

Looking forward to further discussion.

[KromatikaFinance]

This is a brilliant proposal. It’s about time to get this rolling.

Kromatika is built on Uniswap V3 and Kromatika’s premium product - Limit Orders (also called FELO - Fees Earning Limit Orders - by Kromatikans) has automated UniV3.

Kromatika supports this proposal and want to contribute in its implementation.

Would be happy to work alongside @ilia_0x and 0xPlasma.

[modong]

Exciting proposal for sure. Mo from Celer Network here. I would love to introduce Celer and also respond to the questions listed here.

A quick introduction to Celer:

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 1 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 network protocols. cBridge, a cross-chain asset bridge solution, has processed $12.2b transaction volume across 31 chains for 200K users.

How to build Uniswap’s cross-chain governance (with a focus on security models)

Celer IM based cross-chain governance is already live in production with FutureSwap since the end of April 2022 and has been operating flawlessly since. The reference implementation of cross-chain governance 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 cross-chain governance, 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 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 cross-chain governance process.

Next, we answer the questions raised in the post.

Does the bridge support arbitrary message passing?

Of course, this is the core of Celer, and all the cross-chain applications are built on top of this functionality. Celer currently supports arbitrary message passing on all EVM-based chains. For non-EVM chains, Celer supports Aptos, Sui, Flow and Cosmos-based blockchains.

Is the bridge secured by a trusted entity, by a multi sig, or a protocol/set of incentivized nodes?

This is briefly discussed in the previous walkthrough. Here, we provide a more detailed description.

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.

1. Cosmos-consensus Security Model

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.

2. Optimistic-rollup-style delay buffer Security Model ( what should be used in this case )

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.

Does the bridge leverage the security of the source chain (e.g. Ethereum L1) or destination chain, or is security provided by another third party entity?

When operating in the model of Optimistic-rollup-style model, the security is dependent on the source chain and on the “trust-any” model as described in the security model section. It does not depend on any single third-party entity or a majority of decentralized parties. As long as one single app guardian is still working in a trustworthy way, the system is secure.

Is it possible for a fraudulent message to be passed to the destination chain? If so, are there any recall mechanisms?

When operating in the model of Optimistic-rollup-style model, as long as there is still one app guardian that is trustworthy, it is not possible to have any fraudulent message to be passed to the destination chain.

This is very different from other models where when a majority (often 2/3) of validators/MPC signers are compromised, a fraudulent message can be passed to the destination chain.

What are the ramifications of fraud to the malicious actor?

Their CELR stake will be slashed.

Has the bridge code been audited? By a third party? What attack vectors and vulnerabilities were identified, if any? Have the identified vulnerabilities been remedied?

Celer was audited by Certik, Slowmist and Peckshield. No vulnerabilities were identified in any of the audits. We also have a $2M standing bug bounty on Immunefi that is not claimed yet. Celer is the only cross-chain system that has processed more than $1b with no vulnerability exploited or identified.

[devinwalsh]

Thank you! In this case, would Uniswap have to commission SGN to run an App Guardian? I don’t know of anyone running one for Uniswap today.What would the process be to do that?

And, in that case, would there only be 1 App Guardian confirming messages against Ethereum during the delay period? How many Guardians are deployed for other apps - would it be wise to commission multiple?

Correct me if I’m misunderstanding anything here.

[modong]

All great questions.

When building cross-chain dApps in the optimistic-rollup-style security, all SGN nodes will run the app guardian process for this dApp. In addition, any application developer whitelisted entity can run an app guardian for this app. In this case, we can run an additional app guardian for Uniswap’s cross-chain governance use case and talk to our long-term security partners, such as Peckshield, to run one for Uniswap. Of course, Uniswap foundation can also run an app guardian for this use case.

So to answer your question, yes, there will undoubtedly be multiple app guardians for Uniswap and quite a decentralized group of guardians. It is straightforward to run an app guardian as it is a simple deployment process.

[devinwalsh]

Thank you - this is helpful.

As for the number and identity of the SGN of validators - looks like there are 21, who are identified here? SGN Web

So all 21 of these validators would also be running the App Guardian software for Uniswap. I’m definitely interested in potentially having an additional App Guardian run on Uniswap’s behalf so will follow up with you on that.

[modong]

That would not be a problem at all. In addition, we are actively working on a zk succinct proof based solution that will further enhance security for use cases like governance.