CIP-XX Improve the liquidity efficiency of cBridge

Celer Community,

As a seasoned member of the Celer community and an experienced on-chain player, we present this CIP for consideration by the community’s developer team. The aim is to enhance the liquidity efficiency of cBridge and curb the unnecessary emission of rewards.

Here’s a brief summary:

With the current market demand for cross-chain bridging, the liquidity pool model that Celer’s cBridge currently utilizes is not maximizing liquidity usage for USDT, USDC, and ETH, thereby resulting in considerable wastage of reward emissions for idle liquidity. However, Celer already possesses the solution to this predicament: Peti, a completely decentralized, non-custodial, multi-blockchain liquidity RFQ protocol for professional liquidity providers. It is built on the core of the Celer Network’s cross-chain messaging.

The advantage of Peti lies in the fact that liquidity is only called from a pool of permissionless liquidity providers when required. Consequently, there’s no need to lock up a common and persistent pool of liquidity and bear the cost of liquidity rewards for excess and idle liquidity.

This proposal contends that Peti should become a parallel liquidity model for cBridge and auto scale with the pool-based solution as the market condition changes . This transition will considerably enhance liquidity efficiency and thereby reduce the expenditure of liquidity pool rewards for the protocol. However, we acknowledge that shifting from the existing always-on liquidity pool model to a just-in-time liquidity pool model is not a straightforward task. We outline a strategic roadmap to facilitate this transition in this proposal.

It is important to clarify that transitioning to a Peti and pool-based parallel model doesn’t imply discontinuing the pool-based liquidity model. They should function hand-in-hand. The ultimate objective is an architecture where the pool-based model manages most smaller and frequent transactions under the present-time market condition, while Peti oversees larger but less frequent transactions. Moreover, both systems should auto-scale in response to actual market demand.

Motivation: Addressing the Inefficiency of the Current xLiquidity Pool-Based Model

How does xLiquidity function?

As quoted from Celer’s documentation, “xLiquidity is designed for a token that has been deployed across different chains and does not adhere to the cBridge standard. To support bridging, liquidity pools are established on various chains. When users transfer between these chains, they deposit their tokens into the pool on the source chain and withdraw a corresponding number of tokens from the pool on the destination chain, based on a bridge rate produced by the StableSwap pricing curve.” These liquidity pools of USDT, USDC, and ETH are maintained by the emission of liquidity rewards for liquidity on each chain. Any imbalance in liquidity is adjusted by both the pricing curve and the difference in reward per unit liquidity, pushing towards a more balanced configuration.

The Decline in Blockchain On-Chain Activities Leads to Low Liquidity Efficiency Factor

In a bustling market where the demand for cross-chain bridging is high, the Liquidity Efficiency Factor (LEF)—defined here as the ratio of the average daily cross-chain transfer volume to the size of the liquidity pool—is generally high. For instance, in July 2022, cBridge’s LEF for USDT, USDC, and ETH was 3.4, signifying that the daily volume traversing through cBridge was more than triple the locked liquidity.

However, as the overall trend in 2023 unfortunately demonstrates, user activity for all on-chain applications, including DeFi, gaming, and social platforms, is declining. This trend has significantly reduced the global demand for cross-chain bridging. Consequently, cBridge’s LEF has been falling and recently hit a new low. In June 2023, LEF plunged to an all-time low of 0.14.

This low LEF suggests that most of the liquidity in the pool is currently idle and not being utilized. This essentially points to two issues:

  • The fees collected by the liquidity providers per unit liquidity are low, leading to little or no incentive for them to rebalance and collect more fees.
  • A large portion of the liquidity incentive rewards is being wasted.

It is apparent that the current market conditions necessitate a reassessment of the existing liquidity pool model. The demand for a model with improved liquidity efficiency is unequivocal.

Proposal: A Parallel Liquidity Model Incorporating the Peti RFQ Model

Understanding Peti’s Functionality and Its Potential for Enhanced Liquidity Efficiency

For a detailed understanding of Peti, you can refer to the explanatory post on Celer’s blog post here. Originally, Peti was conceived as a cross-chain RFQ protocol, designed to connect with professional liquidity providers for managing substantial cross-chain transactions when the pool size proved inadequate (e.g., multi-million transactions). The key to Peti’s higher liquidity efficiency lies in its “just-in-time” model, as opposed to the traditional “always-on” approach. Professional liquidity providers are not required to lock their liquidity in a smart contract, allowing them to employ their liquidity in other yield venues and only draw upon it to respond to a bridging request when necessary. Consequently, the expected return for these professional liquidity providers, even with certain SLA, is generally lower than that of today’s liquidity pool. This is particularly true when the bridging requests are sporadic, thereby obviating the need for providers to lock up liquidity for extended periods.

Transitioning from a “Tiered Model” to a “Parallel Model”

Currently, Peti functions within a “tiered model,” wherein the pool model is primarily utilized, and only when pool liquidity falls short do liquidity providers step in to supply the required liquidity via the RFQ model. We suggest that Celer cBridge transition to a “parallel model,” in which both the Peti and pool-based models are simultaneously employed for all transactions. Users will be directed to the route offering the lowest overall fee, and in cases where the fee is identical, Peti should be chosen as the default route to amplify its practical usage.

The advantage of the parallel model is that it affords cBridge greater flexibility to scale both models in alignment with market conditions. In the current climate of low demand, the liquidity pool-based model can function in a non-dominant fashion with lower overall liquidity, thereby mitigating unnecessary emission of liquidity rewards, and allowing the Peti model to handle most of the volume. Conversely, when demand surges, the protocol can expand the liquidity pool size with enhanced rewards to provide always-on liquidity, thus making the liquidity pool-based model the primary operational model.

Implementation: A Gradual Transition

Naturally, transitioning into the final parallel model, combining Peti and the pool-based model, won’t happen overnight. We have identified the following necessary steps for this transition:

Step 1: Align Liquidity Incentives with Overall Demand

Although not directly tied to the transition, this step should be implemented regardless. The current LEF indicates that the reserve liquidity significantly exceeds the liquidity actually required. Based on daily volumes and demand, we suggest the following liquidity reward reduction schedule to better align with the real demand for cross-chain bridging. The Adjust Ratio is defined as the ratio between the new liquidity reward emission rate and the previous one.

Proposed Adjust Ratio Arbitrum One Avalanche BNB Chain Ethereum Mainnet Polygon Optimism Astar Aurora
USDC 0.2 0.2 0.3 0.3 0.2 0.2 0.05 0
USDT 0.2 0.2 0.3 0.3 0.2 0.1 N/A 0
WETH 0.2 0.1 0.2 0.3 0.2 0.2 N/A N/A

Note that we propose Aurora should be removed from the support of liquidity pool-based model because of its minimal usage.

This step should proceed irrespective of the Peti model switch, given the current excessively low LEF. Adjusting the liquidity rewards can generally improve liquidity efficiency, and by decreasing overall liquidity, it creates more room for professional liquidity providers operating under the Peti model. The proposed adjustment schedule is extremely conservative and highly unlikely to affect current bridging usage. In fact, we suggest that the ideal LEF should be around 1.5 (ten times the current value), necessitating a total liquidity reduction of approximately 10 times. However, the adjustment itself is not that drastic to avoid any unforeseen issues. Following this adjustment, we recommend that the community continually evaluates the LEF and makes necessary adjustments on a monthly basis.

Step 2: Launch a Call for Proposal (CFP) for Liquidity Providers

Upon completing the first step, a public Call for Proposal process should be initiated to invite professional on-chain liquidity providers to submit proposals for offering liquidity under the Peti model. The format of the proposal can be discussed, but should include the following key metrics:

  • Chain and token to be supported

  • Availability guarantee

  • Average volume capacity commitment per day per chain per token

  • Maximum delay to handle a bridging request

  • Pricing structure

  • Liquidity provider’s pricing structure (flat fee, volume-based fee, transaction size-based fee)

  • Reward and incentive grant structure

  • Additional liquidity provider rewards required

  • Schedule of such an incentive structure (should be related to availability guarantees, penalties, or reductions to liquidity rewards if availability guarantee is violated)

The community should discuss and vote on the liquidity reward grants for these liquidity providers.

Step 3: Transition to an Auto-scaling Model

Following the completion of the CFP, the protocol can further decrease the pool-based liquidity to a level sufficient to handle primarily smaller transactions, with larger transactions primarily managed through the Peti model.

This will provide cBridge with an improved structure moving forward as it will establish a group of dedicated liquidity providers actively servicing Celer cBridge. This cultivated group of liquidity providers will be extremely beneficial for the entire Celer community.

As future demand increases, the liquidity pool can be dynamically scaled up to maintain a reasonable LEF. The threshold for maximum cross-chain volume will correspondingly increase. This will result in a better structure that essentially achieves auto-scaling between the two models, with Peti still focusing on relatively large, infrequent transactions while the pool-based model can handle smaller transactions.

It should be noted that the third step is not fully fleshed out at this point, but it’s crucial to outline it here. In this proposal, our main focus should be on the first and second steps of the roadmap. If the general sentiment check passes, I would call for a snapshot vote for 1. The reduction of liquidity pool rewards, and 2. The initiation of the CFP process.

  • Support the proposal
  • Reject the proposal

0 voters

1 Like

looks cool, will cbridge be faster?

hope the inclusion of Peti can maximize the liquidity usage

Just saw this today. First of all, thank you for the well-thought through proposal. I can see you put a lot of efforts in this. I think you are 100% right that the liquidity efficiency for cBridge is not at its best in the current market condition and it can be improved. Peti is definitely a good solution. The source code is fully open source and anyone can actually connect to this system. Besides you guys, there are a few pro market makers who are interested in this. So this is definitely a great discussion that the community shoudl have through a CFP process.

If we see any significant support from the forum discussion, we can move this to voting. However, I think we should break this down into multiple proposals. The CFP process should be its own discussion and then voting. How do you think if we focus this first proposal on just the liquidity reward reduction?

1 Like

We are also one of Celer cBridge’s liquidity provider and large network delegator, we support this proposal in principle. However, we feel that this proposal is too big and the second two parts are not very well thought through. For example, we should have a full community discussion about how the CFP process works for professional liquidity providers and a separate vote on those. So I think for the sake of moving this forward, let’s create a governance voting process just for the liquidity reduction proposal mentioned in step 1. This step should be done regardless and can be implemented without hurting the existing performance of the protocol.

3 Likes

Great proposal!! I fully support the proposal to integrate Peti as a parallel liquidity model for cBridge, as it will significantly improve liquidity efficiency and reduce wastage of rewards for idle liquidity.

It sounds fantastic! However, I have a question regarding the measurement of the liquidity reward adjustment’s impact. How should we assess the LEF after reducing the liquidity rewards?

This is a great proposal. To be honest, I think the liquidity adjustment ratio should even be a bit lower.

One thing I wanted to note is that though launched on mainnet, Peti seems to be not battle tested like the current pool-based bridging model. I would say the community should vote to sponsor additional security audits for Peti. This would make it easier for pro market makers to get interested in this as well.

2 Likes

The proposal is excellent. I’d like to hear additional thoughts from the community and understand the next steps moving forward.

The analysis here is awesome. Can you share the raw data for the analysis?

1 Like

Let’s move this to the snapshot vote.

1 Like

Interesting - a solid analysis. You have my vote.

This proposal is long overdue. The liquidity reward is more than $2M per year while most of the liquidity is actually just staying idle. 100% support this.

1 Like

It sounds fantastic. This approach provides a great opportunity to maximize liquidity utilization and derive benefits from Peti.

Thank you ser. I will restructure this overarching proposal into smaller actual votable proposals.

This is not exactly related to the speed of cBridge, it is more for liquidity efficiency

This will continuously be a topic of discussion for sure. But we can evaluate the LEF month by month for three months after the adjustment.

This I do agree. That’s why this should be a gradual rollout!

I think it is roughly $2.5M give or take depending on the market, so yeah, should 100% optimize that.