Deep into the Decision: Uniswap selected Axelar Cross-Chain

Uniswap just selected the protocols for their cross-chain governance, where 2 out of 6 cross-chain protocols were chosen. The considered protocols were Axelar, Wormhole, LayerZero, Celer, deBridge, and Multichain, and the cross-chain protocols that were chosen are Wormhole and Axelar (with the condition that they have to move away from using 4 out of 8 multisig that have the ability to change protocol parameters, of which Axelar has already moved forward with these updates).

The Uniswap community has thoroughly studied the aforementioned six protocols before making the decision to select the ones that best suit their cross-chain governance. In this article, we will explore the reasons why Uniswap decided to use Axelar and Wormhole and why the other four options were not selected.

Let’s start with the first two protocols, Axelar and Wormhole.

Axelar

Axelar is a protocol that utilizes a dPoS (delegated Proof of Stake) system to ensure the security of cross-chain data. Currently, Axelar connects to over 43 chains and has more than 75 validators. The main reason Axelar was chosen is due to its utilization of the dPoS system, which imposes penalties if validators violate the rules. This mechanism acts as a disincentive, discouraging collusion among validators. Axelar also implements quadratic voting with their dPoS to help reduce the centralization of the staked tokens. Additionally, the number of validators is relatively high, with 70 validators during Uniswap’s evaluation and 75 validators currently. Axelar places great emphasis on security, undergoing rigorous audits, bug bounty programs, and maintaining continuous development efforts led by the Axelar team.

One notable advantage of Axelar is the transparency of its protocol. It ensures transparency in the validator’s operations, which can be verified through their website, as well as transparency in their protocol parameters.

Although Axelar seems to be perfect so far, every protocol comes with risks. For example, the use of dPoS with 70 validators during Uniswap’s evaluation, along with a 60% threshold, results in the minimum number of validators required to sign the validity of a message being 30 validators. This measurement is based on the staked tokens, not the number of validators. Consequently, it is possible to collude with a lower number of validators than half of the total validators. However, Uniswap believes that launching an attack would be challenging, taking into account factors such as the use of quadratic voting, the number of locked tokens, and the time required for an attack to take effect. Furthermore, Axelar implements a rate limit, which helps mitigate damage by setting a maximum limit on the assets that can be transferred through Axelar within a specific time window.

Wormhole

Many readers may be familiar with the bridge called “Wormhole.” It operates on a PoA (Proof of Authority) system, where validators utilize their reputation as a stake, unlike dPoS, which uses assets or tokens as a stake. Currently, Wormhole has a total of 19 validators, also known as guardians, most of whom are well-known organizations in the cryptocurrency space. The main reason Wormhole was chosen is due to its relatively large number of validators for a PoA-based protocol, and each validator is considered reputable. The cross-chain messages are deemed valid when 2 out of 3 or 13 out of 19 validators agree on them.

However, despite using reputable validators in the PoA system, there are still inherent risks. The issue with PoA is that quantifying reputation as a measurable quantity is challenging. Consequently, comparing reputation with the value of assets locked within the protocols becomes difficult. This makes it hard to predict when the protocol may become the target of attacks. In contrast, PoS or protocols that employ assets as collateral allow for more accurate risk assessment as the staked or collateral assets of all validators can be compared to the value the protocol aims to secure.

Another risk is regarding the performance of the Wormhole’s validators. With more than 15,000 cross-chain transactions between Ethereum, BNB, and Polygon, there are at least 3 validators with a participation rate below 50% and 1 validator with a participation rate below 21%. This is worrisome because Wormhole’s liveness hangs on 1 out of 3 or 7 validators. This means that if three more validators are absent (plus the poor performance of the above-mentioned four validators), Wormhole may stop functioning.

Additionally, there are concerns about the validation incentive. Wormhole does not incentivize validators to independently verify the source chain data. Currently, Wormhole requires only one validator to pick up events on the source chains, and then that validator just gossips the events to the remaining validators for validation. This approach carries risks, as the other validators do not independently verify the data from the source chain. If the data being transferred is malicious, the validators who solely rely on the gossiped data for signing may not be aware of the potential risk because they did not personally inspect the actual data themselves.

We have just finished discussing the two bridges that were selected for the Uniswap use case. Now, let’s continue this article by exploring the remaining four bridges that were not chosen this time but have the potential to be selected in the future with updates and improvements. We will begin with the first bridge, LayerZero, which has gained significant popularity recently, mainly due to rumors surrounding an upcoming airdrop.

LayerZero

LayerZero has claimed themself as a trustless bridge. LayerZero relies on cross-checking between two components, a Relayer and an Oracle on verification layer to validate the cross-chain message validity. The data is considered valid only when both the Relayer and the Oracle agree on its correctness. However, this system is not as secure and trustless as many people believe, due to the number of nodes that operate Oracle and Relayer.

Currently, the most secure Oracle for LayerZero is Chainlink’s Decentralized Oracle Network (DON), which has only four nodes, which collaborates with a Relayer from LayerZero. Data is considered valid when it receives confirmation from at least 3 out of the 4 Oracle nodes and 1 from the Relayer. Clearly, LayerZero is not trustless as claimed, as it relies on trusted nodes, which are only 4 out of the 5 nodes. This process can be seen as utilizing a Proof of Authority (PoA) mechanism. Using such a small number of parties to secure the protocol carries significant risks, especially if the assets being managed by the protocol have very high value.

Another problem that arises when using a single node of Relayer is that if the Relayer goes offline (due to an attack or any other reason), the protocol will come to a halt, and it will not be able to operate until the Relayer returns. In this case, the protocol will lose its liveness.

However, it doesn’t mean that LayerZero has no chance of being selected in the future. Currently, LayerZero is preparing to update itself to use a higher number of Oracle and Relayer nodes. There are also news reports suggesting that the protocol will be updated to utilize the Zk Light-client, which could potentially increase the security of LayerZero. These updates and improvements indicate that LayerZero has the potential to address the issues and enhance its functionality in the future.

Celer

Next is Celer, a protocol that offers low-cost cross-chain fees. Celer employs a dPoS consensus mechanism and offers a choice for applications to choose whether to use the optimistic mode on top of the dPoS, where the applications are responsible for running the watcher service themselves. Currently, Celer has 20 Validators, and the security of the system is maintained through staking the CELR token. However, Celer was not selected because it has not implemented a slashing mechanism within its dPoS protocol [1][2]. Therefore, there is no penalty imposed on a validator who acts maliciously. Additionally, there are concerns about the protocol’s variable updates, which only require a 3 out of 5 multisig, and the project’s documentation lacks detailed explanations of its protocol. The judging team had to study the code to understand how Celer operates, and there are articles discussing security issues related to Celer’s validators or guardians.

deBridge & Multichain

For deBridge, which was also not selected, the reasons are similar to Celer. They have plans to implement slashing and staking in the future, with only 11 validators currently.

In contrast to the previously mentioned protocols that utilize PoA and dPoS, Multichain takes a different approach to ensure the security of its bridges. It employs a permissionless Multi-Party Computation (MPC) to validate cross-chain data, allowing anyone to participate in the process. However, a challenge arises as MPC lacks penalties, which means that there are no disincentives for malicious validators, unlike in dPoS, where penalties exist. Additionally, the open participation model means that validators are not required to rely on reputation as a guarantee.

The absence of disincentives to prevent cheating, resulting from the lack of penalties, and the inability to determine whether validators are truly independent pose concerns for the protocol’s decentralization. Without effective mechanisms in place to deter malicious behavior and maintain the integrity of the system, questions may arise regarding the reliability and trustworthiness of Multichain as a bridge protocol.