This proposal will authorize 0xPlasma Labs to deploy the Uniswap v3 protocol (Fee Tier: 1, 0.3, 0.05, 0.01) 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).
Total Value Locked - $3.65B
Chain Breakdown Ethereum - $3.41B Polygon - $101.93M Arbitrum - $85.08M Optimism - $47.04M Celo - $1.26M
Potential TVL from BNB Chain: 1/2 * $2.36B (PancakeSwap) ~ $1.18B
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.
0xPlasma Labs would like to propose using Celer Bridge for the Governance cross-chain messaging.
Here is a piece of information about the Celer Bridge provided by @modong
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.
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.
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.
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.
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.
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.
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.
Their CELR stake will be slashed.
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.
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.
This proposal will authorize 0xPlasma Labs to deploy the Uniswap v3 protocol (Fee Tier: 1, 0.3, 0.05, 0.01) 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).
Total Value Locked - $3.65B
Chain Breakdown Ethereum - $3.41B Polygon - $101.93M Arbitrum - $85.08M Optimism - $47.04M Celo - $1.26M
Potential TVL from BNB Chain: 1/2 * $2.36B (PancakeSwap) ~ $1.18B
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.
0xPlasma Labs would like to propose using Celer Bridge for the Governance cross-chain messaging.
Here is a piece of information about the Celer Bridge provided by @modong
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.
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.
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.
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.
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.
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.
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.
Their CELR stake will be slashed.
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.
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.
https://gov.uniswap.org/t/rfc-update-deploy-uniswap-v3-1-0-3-0-05-0-01-on-bnb-chain-binance/19734/26?u=gfxlabs
https://gov.uniswap.org/t/rfc-update-deploy-uniswap-v3-1-0-3-0-05-0-01-on-bnb-chain-binance/19734/26?u=gfxlabs
the threat to reputation is a centralized network, and all the assets of the network also belong to a centralized structure. At any moment, when something goes wrong with such a structure (are you remember attention SEC to Binance this summer?), all users will suffer. Including UniSwap users! It should be understood that the UniSwap brand today is a sign that the network can be trusted. The deployment of UniSwap on BSC will not attract BSC's users - they already have PancakeSwap (UniSwap v2 fork), but will pull users of other protocol networks into transferring funds to Binance-USD derivatives (all assets in BSC by Binance) and BNB purchases to pay for gas.
I understand you want to make money before April (Business-license), but what will happen after April (SEC can arrest CZ?)?
the threat to reputation is a centralized network, and all the assets of the network also belong to a centralized structure. At any moment, when something goes wrong with such a structure (are you remember attention SEC to Binance this summer?), all users will suffer. Including UniSwap users! It should be understood that the UniSwap brand today is a sign that the network can be trusted. The deployment of UniSwap on BSC will not attract BSC's users - they already have PancakeSwap (UniSwap v2 fork), but will pull users of other protocol networks into transferring funds to Binance-USD derivatives (all assets in BSC by Binance) and BNB purchases to pay for gas.
I understand you want to make money before April (Business-license), but what will happen after April (SEC can arrest CZ?)?
Proofs articles: https://www.bloomberg.com/news/articles/2022-06-06/us-probes-binance-over-token-that-is-now-world-s-fifth-largest https://forkast.news/headlines/philippines-sec-warns-public-not-to-invest-with-binance/ https://www.wsj.com/articles/sec-faces-calls-to-boost-crypto-exchange-enforcement-after-ftx-collapse-11670474070
I believe that the protocol must not be run on centralized networks like binance chain, this can hit the reputation of the protocol very hard!
Outside of the quantitative benefits for the protocol and pending no technical deployment issues, we want to note some considerations on why ConsenSys voted Yes.
Uniswap contracts have naturally established a strong brand that users trust. Although there are general concerns around the centralization of the BNB Smart Chain ("BSC"), we view the protocol’s brand as standalone and not beholden to any particular chain. The DAO will always govern the protocol.
Outside of the quantitative benefits for the protocol and pending no technical deployment issues, we want to note some considerations on why ConsenSys voted Yes.
Uniswap contracts have naturally established a strong brand that users trust. Although there are general concerns around the centralization of the BNB Smart Chain ("BSC"), we view the protocol’s brand as standalone and not beholden to any particular chain. The DAO will always govern the protocol.
Naturally, we prioritize higher volume chains/L2s; BSC has a strong user base and transaction volume. With the Business license expiring in April, it is essential that Uniswap be chain agnostic to serve all users of Web3.
Regardless of personal views, Uniswap entering the BSC market will provide current and future users with a secure and established medium for decentralized exchange.
We encourage Stakeholders, Delegates, and the Community to provide feedback from engaging in the temperature check.
Well why not! They should go for it!
the threat to reputation is a centralized network, and all the assets of the network also belong to a centralized structure. At any moment, when something goes wrong with such a structure (are you remember attention SEC to Binance this summer?), all users will suffer. Including UniSwap users! It should be understood that the UniSwap brand today is a sign that the network can be trusted. The deployment of UniSwap on BSC will not attract BSC's users - they already have PancakeSwap (UniSwap v2 fork), but will pull users of other protocol networks into transferring funds to Binance-USD derivatives (all assets in BSC by Binance) and BNB purchases to pay for gas.
I understand you want to make money before April (Business-license), but what will happen after April (SEC can arrest CZ?)?
the threat to reputation is a centralized network, and all the assets of the network also belong to a centralized structure. At any moment, when something goes wrong with such a structure (are you remember attention SEC to Binance this summer?), all users will suffer. Including UniSwap users! It should be understood that the UniSwap brand today is a sign that the network can be trusted. The deployment of UniSwap on BSC will not attract BSC's users - they already have PancakeSwap (UniSwap v2 fork), but will pull users of other protocol networks into transferring funds to Binance-USD derivatives (all assets in BSC by Binance) and BNB purchases to pay for gas.
I understand you want to make money before April (Business-license), but what will happen after April (SEC can arrest CZ?)?
Proofs articles: https://www.bloomberg.com/news/articles/2022-06-06/us-probes-binance-over-token-that-is-now-world-s-fifth-largest https://forkast.news/headlines/philippines-sec-warns-public-not-to-invest-with-binance/ https://www.wsj.com/articles/sec-faces-calls-to-boost-crypto-exchange-enforcement-after-ftx-collapse-11670474070
I believe that the protocol must not be run on centralized networks like binance chain, this can hit the reputation of the protocol very hard!
Outside of the quantitative benefits for the protocol and pending no technical deployment issues, we want to note some considerations on why ConsenSys voted Yes.
Uniswap contracts have naturally established a strong brand that users trust. Although there are general concerns around the centralization of the BNB Smart Chain ("BSC"), we view the protocol’s brand as standalone and not beholden to any particular chain. The DAO will always govern the protocol.
Outside of the quantitative benefits for the protocol and pending no technical deployment issues, we want to note some considerations on why ConsenSys voted Yes.
Uniswap contracts have naturally established a strong brand that users trust. Although there are general concerns around the centralization of the BNB Smart Chain ("BSC"), we view the protocol’s brand as standalone and not beholden to any particular chain. The DAO will always govern the protocol.
Naturally, we prioritize higher volume chains/L2s; BSC has a strong user base and transaction volume. With the Business license expiring in April, it is essential that Uniswap be chain agnostic to serve all users of Web3.
Regardless of personal views, Uniswap entering the BSC market will provide current and future users with a secure and established medium for decentralized exchange.
We encourage Stakeholders, Delegates, and the Community to provide feedback from engaging in the temperature check.
Well why not! They should go for it!
Let's make this happen!
Let's make this happen!
Appreciate your feedback. You can give a more detailed statement on how that deployment will affect the reputation of the protocol and vote on the snapshot.
Appreciate your feedback. You can give a more detailed statement on how that deployment will affect the reputation of the protocol and vote on the snapshot.
