Comparison — Hop and cBridge For Cross Layer Transfer

This article is part of our cross-layer transfer series, and I have prepared the list below, which helps the reader navigate easily through the articles.

1. An Introduction to Cross Layer Transfer
2. Fast Withdrawals In Optimistic Rollups — Part 1
3. Fast Withdrawals In Optimistic Rollups — Part 2
4. Standardising Cross-Domain Asset Transfer
5. Cross Layer Transfer — Hop Protocol
6. Cross Layer Transfer — CELR cBridge

Introduction

We have already discussed different cross-layer transfer protocols that help users transfer their assets between different layer 2 and layer 1 solutions. Hop Protocol (the default CLT protocol for Optimism PBC) and CELR cBridge take a significant share of transfer volume among the CLT protocols. Therefore, it will be advantageous for an end-user to learn and understand the features and comparison between these protocols. Keeping that in mind, we will compare the features between Hop Bridge and cBridge v1.0 and v1.2. We will first define the parameters we have chosen for comparison and then prepare a comparison table. Please note that this article will take an unbiased approach, and the user can decide which protocol suits best for them.

Now, let’s quickly go through a brief architecture about Hop Protocol and cBridge. If you want to learn the detailed architecture, please go through our previous articles that describe them best. (Hop Protocol, cBridge v1.0).

Architecture in Brief — Hop

Hop Protocol allows users to quickly and easily transfer tokens directly between layer-2s, sidechains, and layer-1 Ethereum, enabling a composable and interoperable layer-2 ecosystem for Ethereum.

It describes itself as a scalable rollup-to-rollup general token bridge, allowing users to send tokens from one rollup to another almost immediately without waiting for the rollup’s challenge period.

The Hop protocol provides a scalable token bridge for Ethereum’s layer-2 ecosystem using a two-pronged approach:

1. Create a special intermediary asset called an hToken (e.g., hETH, hDAI, etc.) that can be quickly and economically moved from one network to the next that allows for trustless swaps.
2. Use Automated Market Makers (AMMs) to swap between the hTokens and their corresponding assets on each layer-2 network.

A significant difference between the Hop and cBridge is that Hop doesn’t use HTLC based contracts; instead, it requires Bonders to lock liquidity upfront in on-chain contracts. The Bonder responds to user CLT requests and collects the fees for a successful transfer operation.

With those in place, Hop allows users to move tokens directly onto and out of Ethereum, Polygon, xDai, and Optimistic Ethereum, Arbitrum in minutes, with more networks to follow.

Architecture in Brief — cBridge 2.0

CELR has recently upgraded its cBridge version from 1.0 to 2.0 with many new features. These new features give various opportunities both for an end-user and liquidity provider. However, there are notable differences between these two versions, and we will discuss the significant changes here. When writing this article, cBridge 2.0 is still in beta, and cBridge 1.0 has a stable release.

cBridge v2.0 offers two models for liquidity providers. The core idea behind these two models is how the Liquidity providers manage their liquidity. The cBridge 2.0 enables the Liquidity providers to either run a self custodian cBridge node or delegate the liquidity to a shared liquidity pool. Let’s discuss these two models in detail below :

1. SGN(State Guardian Network) as a cBridge node gateway and Service Level Agreement (SLA) arbitrator

This model allows the liquidity providers to run their cBridge node and provide liquidity for CLT requests. An important advantage is that the liquidity providers have custody of their funds and don’t need to lock it in any on-chain contract. Also, this model removes the old centralized Gateway server for cBridge node scheduling. Instead, it uses the SGN as a Gateway service which selects a cBridge node to facilitate a CLT request. The selection rules are written in the SGN chain (Proof of Stake based chain), and the Governance process can change the rules.

2. SGN as a Shared Liquidity Pool Manager

In this model, SGN manages shared liquidity pool contracts on multiple chains. ( So, this treats the SGN and its managed liquidity pool as a single node). LPs can delegate liquidity to these pools without the hassle of running a cBridge node. Please note that this model can work along with the previous model. So, there can be non-custodial LP-managed nodes plus SGN itself as a node.

The advantages for LP in cBridge 2.0 are:

1. Compared to cBridge v1.0, the LP now has two options to manage its liquidity. It helps those LPs who don’t want to run their cBridge node.
2. There is no use of any synthetic tokens, and as a result, there won’t be any complex process involved when the LP tries to rebalance the liquidity across the chain manually. Please note that arbitrageurs can also come into the picture and help rebalance the liquidity by spotting better arbitrage opportunities.
3. Compared to the old centralized gateway server mechanism, node scheduling is now done through SGN.

Advantages for User:

1. The user can now complete a CLT request in a single click compared to two operations in cBridge v1.0.
2. Users receive compensation if the cBridge node goes offline or unavailable before processing a CLT request.

Comparison Parameters

First, let’s define the parameters that we are using to compare the protocols. Of course, the list is not exhaustive, and we welcome any new suggestions which readers wish.

1. L1 interaction

Mainly, the user wish to perform the below three operations

a) L2 <-> L1 Transfer

b) L2 <-> L2 Transfer

c) L1 <-> L1 Transfer

L1 interaction should be kept minimum or none for l2-l2 transfers unless the protocol provides any significant advantage to the user for routing through L1. It is because routing the request to L1 will again add considerable overhead to the base layer and incur high fees to the user. So to achieve minimal L1 interaction, liquidity provider-enabled fast withdrawal models require liquidity available in different chains (such as Optimism, Arbitrum, Ethereum, etc.). The protocol should also define the rules or mechanism for selecting LP nodes, fee calculation, and how the user can reclaim funds in unforeseen circumstances.

2. Guarantee / Confirmation

Does the protocol guarantee the success of every transfer? If not, How long will it take the user to get their funds back in an unforeseen circumstance? For example, the Bonder and cBridge node is unavailable or not willing to serve a request.

3. Bonding / Slashing mechanism for LP unavailability

Does the protocol provide any mechanism to penalise the Bonders or nodes for not serving the transfer request? Depending on the protocol, if the user request is not served due to unavailability of the LP nodes, then the user might have to wait 12hours — 7 days to get their funds back.

4. Upfront Liquidity locking

Does the protocol require the LP to lock their liquidity upfront in an on-chain contract?

5. Custodial / Non-custodial

Moving funds through a custodial bridge is no different than moving funds through CEX. However, it is in the best interest of both users and LP to use non-custodial bridges for their safety.

6. Availability of Canonical Tokens

7. Fee Comparison

To give a much better clarity for the community, we used both Hop Protocol and cBridge v2.0 for transferring 0.1 ETH each from Optimism to Arbitrum. The below data helps you get a much better understanding.

CLT Transfer → Optimism to Arbitrum (Please note that WETH transferred using cBridge from Optimism to Arbitrum)

Conclusion

Hop protocol and cBridge are gaining more user adoption and total market share in the CLT space. Optimism has adopted Hop as the default bridge for CLT transfer. User adoption will occur based on how comfortable it is to use the bridge, the safety of the funds involved, fee structure and incentives for users and LP, less complexity while rebalancing the liquidity, etc.