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

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.
1 Like

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
1 Like

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.

5 Likes

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.

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.

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.

  1. 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.

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.

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.

1 Like

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.

1 Like

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.

What is the status on the temperature check? we should have a vote as soon as possible. I will be delegating to GFXlabs. Bridges discussion can be held seperate.

I plan to do a temperature check this week!

Thank you @ilia_0x for this proposal.
Speaking on behalf of BNB Chain foundation side, we are welcoming this idea and are humbled by this proposal.

We will also be happy to provide all the necessary support for a successful deployment on the chain if the vote pass.

1 Like

Does anyone think about the risks?

1 Like

Hi Everyone,

We’ve been doing a bit of research on the testnet deployment. Below is a list of the immediately relevant contracts:

  • BSC Testnet Uniswap V3 Factory contract: link
  • BSC Testnet Message Receiver Adapter: link
  • BSC Testnet Message Bus: link
  • Goerli Message Bus: link

Test use of the Celer Messaging system:

  1. Message sent from Goerli: link
  2. Message queued for execution on BSC: link
  3. Message executed: link

At a high level, we can see the Uniswap v3 protocol has been deployed on testnet and that Celer successfully passed a message from an EOA on Goerli, which implemented an additional fee tier on the BSC testnet deployment.

Overall, we’re pleased with the work that Ilia and his team have performed.

However, in reading through Celer’s deployed contracts and documentation, we have a few concerns and questions we would like addressed.

The Message Bus contracts on Ethereum and BSC mainnet have an owner role. The owner controls access to the following functions: setFeePerByte, setFeeBase, setLiquidityBridge, setPegBridge, setPegVault, setPegBridgeV2, setPegVaultV2, and transfer ownership. In addition to this access, since the contract is upgradable, the owner is able to upgrade the implementation of the contract, which means anything is possible. The owner on the Message Bus contracts is the “SimpleGovernance” contract. However, the governance contract functions akin to a multisig since it has five voters with equal voting power. We were unable to find information regarding the five EOAs on the contract, however they appear to be active.

  1. 0x1b9dFC56e38b0F92448659C114e2347Bd803911c
  2. 0x34dFa1226F8b3E36FE597B34eEa809a2B5c0bBf9
  3. 0xDfE4F07D1F36B8d559b25082460a4f6A72531de2
  4. 0x9F6B03Cb6d8AB8239cF1045Ab28B9Df43dfCC823
  5. 0x2FB8783C14A71C08bFC1dE8Fc3D715Dd93039BF2

After reading through the contracts, we tried to find more information on how their “Optimistic-rollup-style” security model works. We were able to find this blog post & doc page, but it only had the same information from the forum post. We did find this reference to a “DelayedTransfer”, but it is unclear how this is “optimistic-like” rather than a simple delay.

We were also unable to find documentation or implementation instructions for running an app guardian. If the Celer team could please share the technical documentation and implementation of their proposed security model, we would appreciate it.

While the messaging contract appears to have been audited, their audits are from PeckShield & Slow Mist which do not inspire a high degree of confidence. Both audits were conducted in February 2022, before the addition of the delay mechanism.

We continue to be supportive of a Uniswap v3 deployment on BSC; however, the Celer team controlling ownership of the Message Bus and limited information on the security model makes it hard for us to support the proposal.

Additional Resources:

4 Likes

Thank you for the comments and questions. I wanted to reply here first to acknowledge the receipt of your comments. However, since today is the Lunar New Year and many of our team is on family or religious holidays, a detailed reply with technical documentation updates might be a bit delayed. Apologies for this and we will reply as soon as we can.

1 Like
1 Like

I explained above that since BNB Chain doesn’t have a canonical bridge, any interoperability solution will inevitably have a validation layer and Uniswap governance will still have to bear the risk that participants of the validation layer will not collude.

zk, optimistic — are just different implementations of the validation layer. As an example, here is an article from L2Beat with an interesting experiment that shows that “oracle and relayer” implementation of the validation layer is a 2/2 consensus mechanism, where validation of headers/proofs doesn’t add any security guarantees, but only gas costs since oracle and relayer can always collude.

I think the best way to move forward for Uniswap is to have a framework for bridges so that instead of relying on a single solution, Governance decisions are sent from Ethereum to other chains (e.g. BNB Chain), my multiple bridges. The passed decision is executed on the destination chain only in case the content of the messages sent by all bridges participating in the framework is matching.

deBridge team can help to prepare this framework so that Uniswap governance can have an established process for adding any new chains in the future

2 Likes

GFX Labs team, thank you again for your questions. We would love to provide some responses to your questions.

On audits and security track records

First, we would like to elaborate a bit on our security audits and track records. We respect that different people may have different opinions about security firms, but we believe that both Peckshield and Slowmist are well-regarded security audit firms. Peckshield, in particular, has been consistently the first to report many security incidents and coordinate major security investigations with top security researchers and firms such as banteg, samczsun, and others. If you have any specific concerns about the quality of these firms, we would be happy to relay them and invite these firms to answer or clarify.

Regarding the audit dates, we built Celer’s system in such a way that our optimistic rollup-like security model can be securely and easily added to dApps as a design pattern. The capability to do so has been available before Feb 2022, and we only began talking about it proactively later when we realized that some teams were marketing it as a unique feature.

In addition to security audits, Celer also has a standing $2M bug bounty on ImmuneFi since November 2021, which has not been claimed yet.

In terms of our security track record, Celer’s cross-chain system is the ONLY ONE that has processed a meaningfully large volume (bigger than $1 billion in asset bridging volume) without any critical security issues being reported or exploited. Additionally, throughout Celer’s development history since 2018, none of the systems or products built by Celer, including the world’s first Generalized State Channel Network, have been exploited in any way. Celer has a security operation team that is active 24/7 to monitor the public blockchain transactions for any anomalies related to Celer’s systems and respond to any reports from security firms and independent security researchers with a 3-minute SLA. Of course, we know blockchain is a dark forest and our flawless record does not automatically guarantee future security, but we hope that the information provided gives you more confidence from a comparative perspective.

On optimistic rollup-like security model

The security model of the optimistic rollup-like system has two components: 1) a two-phase commit pattern in the smart contract, and 2) an off-chain App Guardian that can halt the execution of a message during the delay between commit and confirmation.

We would be happy to explain this in more detail using the DelayedTransfer example you mentioned. DelayedTransfer is related to the optimistic-rollup-like security model used in cBridge, an asset bridge built on the Celer Network. When an asset bridge transaction is initiated and the message is relayed to the destination chain, the message is placed in a DelayedTransfer queue on the destination chain, where it must wait a set delay before funds are released with a confirm transaction.

During this delay, an App Guardian cross-checks the source chain to verify the presence of a corresponding bridge transaction. If a match is found, the App Guardian takes no action and the confirm transaction is executed as normal. However, if a matching transaction is not found (indicating a problem with the bridge), the App Guardian can halt the asset bridge smart contract, preventing any malicious transactions from executing and safeguarding funds. The App Guardian is operated by every validator of SGN and can also be run by additional parties, such as the Uniswap foundation, for their own dApps.

The above security model will be applied to Uniswap’s governance use case. We hope this explanation has provided clarity, but we are available for further discussion via a call or in a Twitter space.

We have recently taken down some of the documentation and reference implementation for the dApp side of the optimistic-rollup-like security model, in order to make it more adaptable for various application use cases. We will follow up with links to the updated documentation and App Guardian repositories within the next two days.

On governance multisig

You are correct in noting that the MessageBus contract is upgradeable through a governance multisig. Our governance process involves a community voting process, and the execution of governance decisions for on-chain contract upgrades is carried out by a subset of validators including InfStone, Binance Staking, OKEX and Celer Foundation.

We made the MessageBus upgradeable with the goal of making it easier to address any potential security issues just in case and add must-have features. However, we approach this process with care and continually evaluate and improve our governance process. We welcome additional active contributors such as GFXLabs to be more involved.

We hope the above clarifies the concerns to some degree and we are always happy to answer any further questions!

Hi Mo, I love the tech that you’re building at Celer, but I think that the Uniswap community may misinterpret a number of your points, so these need to be clarified.

Consensus Model

When you say a “Cosmos-consensus Security Model” or “L1-PoS-blockchain security mode,” someone may interpret that Celer inherits the security model from the Cosmos chain or from the layer-1 where the message was initiated — both of these statements are not the case. Instead, it is accurate to say that with this model, the Celer network is using Tendermint and Cosmos SDK as a set of ready-to-use tools and technologies for implementing consensus and networking layers for the project.

The PoS consensus implementation allows anyone with ⅔ of the voting power (i.e. ⅔ of the amount of staked tokens) to have full control over the consensus and validation of cross-chain messages.

The current total stake is 2,587,158,380 CELR and thus, if nodes with more than 2/3 of the total stake act maliciously, they can forge any message. 7 nodes currently have enough stake to control consensus.

⅔ of the total current stake is 1,724,772,247.33 CELR ≈ $25M at current market price. This is the approximate cost that would allow an attacker to withdraw liquidity from all Celer liquidity pools and forge any message to extract value from any Apps built using Celer Network, and, importantly, I assume the potential value extracted by an attack on Uniswap may be higher than the cost of attack.

The only staked asset is the CELR governance token, which means that validators’ collateral directly correlates with the protocol’s performance. This is why an attacker could open a large short perpetual futures position before attacking the protocol, and recover/hedge the cost of their acquired stake.

Having more than 2/3 of the protocol voting power would allow a malicious entity to control the consensus process and make arbitrary decisions about which blocks to add to the blockchain, forge cross-chain messages, reverse and censor transactions, create fake transactions, and create their own set of validation nodes.

Correct me if I’m wrong, but this attack can be performed by any single whitelisted Celer validator now.

Optimistic security model

You may say that the described problem can be solved through an Optimistic rollup-like security model which is the second alternative provided by Celer. My guess is that this wouldn’t add any additional security to the validation layer for a few reasons:

  1. The optimistic component can always be implemented on the application level, where the receiving smart contract in BNB Chain can have a “quarantine zone” for a configurable period of time, during which whitelisted App Guardians can cancel execution of the message content. If any app can easily add an optimistic component, then why should it be provided by the interoperability solution itself as a second security model?
  2. If an optimistic approach is implemented into the interoperability protocol itself, it delegates responsibility from the validation layer of cross-chain infrastructure to the application, which should elect “App Guardians” who become participants of the new validation mechanism. This approach performs implicit change from the “shared” to “isolated” security model of the validation layer. The reasoning behind why the isolated security model is not suitable for a validation layer can be found in this L2Beat article and my Twitter thread.

I’m not trying to attack a competitor here, I want to make sure that all trust assumptions and risks are made clear for the Uniswap community, as Celer has been endorsed in the temperature check.