<aside> 💡 Assessment conclusion

After assessing the current version of the Celer protocol, the Committee has concluded that it does not currently satisfy Uniswap's requirements as outlined in the assessment framework. Celer employs a proof-of-stake mechanism to secure the protocol. However, the current distribution of stakes and the lack of a functioning slashing mechanism raise concerns about the security guarantees the protocol can offer. Additionally, the lack of transparency around the operations of the validator set and the operational processes that govern important protocol updates highlights areas for significant improvement. There are also areas for notable improvement in the maturity of the codebase, such as conducting better quality audits and improving documentation. The Committee recognizes that the team is working to address these concerns and thus recommend that Uniswap reassess this protocol after a period of at least six months provided these issues are materially ameliorated.

</aside>

Security Analysis Summary

Celer is a general-purpose cross-chain messaging protocol that relies on an external validator set and the cryptoeconomic guarantees that stem from its delegated proof-of-stake mechanism for security. Applications can augment this security model using an optimistic mechanism at the application layer.

Celer's validator set consists of 20 validators that coordinate using a Tendermint based blockchain network referred to as the State Guardian Network (SGN). However, a few entities appear to be running multiple validators, and the number of distinct entities operating validators is likely no more than 18. Most of the validators in the set seem to be identifiable businesses, some of which operate core blockchain infrastructure as part of their primary business. The Celer team has noted that the community has basic diligence processes around validators, but it is unclear whether this process has been applied thus far. Most validators in the current validator set were included prior to this process coming into effect.

Validators stake a bridge-specific token called CELR, which currently has a market capitalization of approximately $153m as of May 25, 2023. The total amount staked by validators represents the overall economic security of the protocol, which currently stands at around $55M. Conversely, the total value locked on the protocol's native token bridge alone is roughly $130m.

Celer uses a linear stake-weighted voting mechanism for consensus. To be considered valid, a message must be signed by at least 2/3 of validators based on their staked assets. With the current stake distribution, this could involve as few as six entities, highlighting the concentration of stake amongst a few entities. If these entities are compromised or collude, the protocol's safety can be violated. Similarly, if more than 1/3 of validators based on stake, which currently amounts to as few as two validators, fail, liveness is compromised. These two validators could also choose to censor messages. Additionally, stake distribution is fluid and may change over time, potentially further centralizing the validator set.

Validators would theoretically be penalized for infractions that could impact safety and liveness, such as extended downtimes and double signing of blocks. However, currently, Celer does not have a functional slashing mechanism. The team has communicated their plans to enable slashing in the next few months.

The Committee believes that the security properties of the protocol do not currently meet the security requirements for Uniswap’s cross-chain governance use-case. Further concerns that inform this decision are outlined below.

Risks and Concerns

• Celer does not currently have a functional slashing mechanism. Slashing is disabled on the Ethereum staking contract, where validators’ funds are locked, but is simulated by validators in the SGN. If validators in the network, detect a slashing condition, the network is halted until operators can manually resolve the issue through a consensus upgrade. In effect, this means that the protocol does not offer cryptoeconomic security guarantees in its current configuration.
• Since the validator network needs to be halted when any slashing condition is detected, a single validator having a prolonged downtime (~12hours), which is a slashable infraction, can halt the protocol for an extended period. This, in effect, means a single validator can impact the liveness of the protocol.
• A notable limitation of the protocol's (theoretical) cryptoeconomic guarantee is that it cannot protect against a scenario in which a quorum of validators collectively violate safety or liveness.
• The protocol provides an optimistic mechanism that applications can optionally use as a fallback if a majority of validators in the validator network are compromised. The current mechanism in which this operates assumes any validator can pause an application by reporting fraud. However, this mechanism also allows any other validator to unpause the bridge in response, effectively negating the benefits this approach could offer in the event of a compromised validator set. It also allows a a single guardian to potentially grief the protocol by reporting invalid fraud.
• The cryptoeconomic guarantees of the protocol rely on a bridge-specific token, CELR, which has narrow utility, relatively low market cap, trading volume and liquidity. Some of the possible implications of this are:
  • The security guarantees of the protocol are subject to the volatilities of this nascent asset. If the price of the asset declines, the economic security of the protocol could be further diminished.
  • The protocol secures significantly more value than the economic security that the staked assets offer. This is illustrated by considering that only ~$36m in current staked CELR can be used to compromise safety, while the the TVL in the protocol’s native bridge is roughly $130M. This could create opportunities for sophisticated economic attacks on the protocol. This is further exacerbated by the fact that the protocol does not have a functional slashing mechanism.
• Currently, there is no visibility into the operation of the central component of the protocol - the validator network. The team does not offer a network or block explorer that enables independent verification of the activities of validators and the actual parameters that govern their operation within the network. However, the team has expressed its intention to address this limitation. An explorer providing visibility into validator and network activity is under development which is due to be released in Q3 2023. Until it is released, one must take the team's assertions on faith as it is currently the only source of truth in this regard. We encourage the team to look at Axelar’s explorer for inspiration on the level of transparency required for a validator network.
• The protocol is governed by a 3/5 multisig, which possesses the authority to make substantial adjustments to the security parameters. This multisig can also be triggered by a 2/5 threshold if required, though the conditions for the latter are not clear. The multisig can enact significant changes to the security parameters of the protocol such as resetting the validator set (which requires a 7 day delay) or withdraw all staked CELR from multiple contracts related to staking.
• The protocol lacks sufficient documentation and crucial details are either omitted or provided at a superficial level. Consequently, the Committee had to invest considerable effort in code analysis and on-chain exploration to gain a comprehensive understanding of the protocol. Furthermore, discrepancies have surfaced between the documentation and the actual implementation or deployment, such as the case of Slashing.
• Additional concerns revolve around the overall quality and maturity of the codebase, including the level of code coverage, and insufficient audits, particularly on the SGN codebase which was not open sourced until the Committee’s assessment commenced, implying this component has not had sufficient time to be vetted by the community and it also not covered by the scope of the bug bounty program. Furthermore, shortly prior to the release of this report, the Committee became aware of a significant vulnerability in the SGN code. This vulnerability, would allow a single validator to compromise safety. The Committee's concerns regarding the maturity of the codebase are further emphasized by this discovery.

Next Steps

The Committee appreciates the efforts of the Celer team thus far, and recognizes that addressing the concerns outlined in the report will take time and effort. The Committee encourages the team to prioritize these issues and make the necessary improvements. Once these concerns have been addressed, it is recommended that the Uniswap Community reassess the protocol for suitability.