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!