An in-depth analysis of the protocol and data

Only two weeks after its initial launch, Stargate, a cross-chain bridge, has already reached a $3.5 billion TVL(Total value locked) and became a star project in the market. In this article, we will briefly overview the technology and operating mechanism of Stargate, and then share our perspectives on Stargate’s future trends based on the recent market data collected.

Note: Nothing in this article constitutes investment advice.

Underlying protocol of Stargate: LayerZero

Currently, the market mainly contains three types of cross-chain protocols: multi-signature notary scheme, relay, and atomic swaps (Hashed Time Lock Contract, HTLC).

• Multi-signature notary, also known as “third party verification,” refers to the process of verifying assets transfer through a third party — usually reputable institutions — and using technologies including multi-party signature to avoid security risks caused by over-centralization. In the current market, cross-chain bridges like , , and are adopting multi-signature notary schemes.

• Relay, also known as “native authentication,” monitors the source chain’s information and packages the records containing the encryption certificate together with blocks of the source chain to the target chain. Currently, native cross-chain bridges of major blockchains in the market tend to adopt relay, including Near’s , Avalanche’s , Terra’s , etc.

• Atomic swaps implement the scheme of HTLC, which pairs cross-chain asset demanders and ensures the simultaneity and consistency of the asset release without trust cost to third-party witnesses. Currently, cross-chain bridges using HTLC include , , , etc.

Bear in mind the three schemes and let’s discuss more about Stargate. Stargate was constructed based on relay — specifically, its underlying protocol LayerZero belongs to relay. Before introducing Stargate, we can first take a look at LayerZero. As a protocol transferring cross-chain information, LayerZero is positioned to be similar to the TCP protocol of the Internet’s transport layer, upon which different dApps can be built. Its principles can be summarized as follows: after chain A’s client packages information to LayerZero’s endpoint, relayers and oracles independently provide proofs of the information as well as the block-update respectively. Specific steps are shown as follows:

1. (Steps 1-3) UA (User Application, which can be interpreted as the contract of a dApp using Layer Zero protocol) packages and transmits the information along with the target chain ID on chain A to LayerZero’s chain A endpoint.
2. (Steps 4-5) The endpoints on chain A send the information to the specified relayer and send the current block ID to the oracle.
3. (Steps 6-7) The relayer receives the proof of the transaction from chain A (the “transaction” here refers to the generalized transaction in the blockchain), while the oracle obtains the blk_hdr (block header) of the block in chain A.
4. (Step 8) After confirming that the block has been confirmed several times on chain A, the oracle sends the blk_hdr to chain B’s endpoint.
5. (Steps 9-13) The endpoint on chain B uses the blk_hdr (block header) to make inquiries to the relayer and obtain information initiated by the UA on chain A with the transaction certificate.

Throughout the process, the oracle of LayerZero uses Chainlink third-party service. The relayer is an off-chain service on which anyone can operate. It is thus clear that the relayer is the “messenger” responsible for transmitting information, while the oracle is the supervisor of the relayer during the transmission. As long as they are independent, the security of LayerZero can be guaranteed. The Chainlink oracle service adopted by LayerZero is already the most mature oracle on the market, which has low probability of colluding with the relayer. The LayerZero protocol allows smart contracts to communicate between blockchains, which can do much more than the asset transfer “cross-chain bridge”. In the future, we may be able to see dApps improving the capital efficiency to a great extent through functions like cross-chain lending, cross-chain aggregator as well as shared states. Users on any blockchain will be able to enjoy all blockchains’ ecology, and the developers won’t need to deploy the projects to each chain one by one.

However, before the realization of all the above, let’s take a closer look at Stargate, the first dApp based on the LayerZero protocol.

The “Liquidity Weapon” of Stargate：Delta Bridge

The most outstanding feature of Stargate is its usage of LayerZero’s ability to transmit information. This helps to connect each blockchain’s funding liquidity, so as to improve the capital efficiency of the system as a whole. Specifically, Stargate users can provide liquidity on only one blockchain, and Stargate’s Delta Bridge algorithm will dynamically allocate the liquidity to other blockchains, while at the same time ensure instant guaranteed finality and native asset transaction properties. These three properties are described by Stargate as a triple dilemma in its . Their meanings are as follows:

• Instant guaranteed finality: After the transaction request is successfully submitted on the source chain, it must be guaranteed to arrive on the target chain as well. In previous cross-chain bridges, the following situations may occur: two users of chain A and chain B may transfer money to chain C at the same time, with the existing liquidity of chain C only able to support one transfer. However, chain A and chain B may not be aware of each other’s transfer demand, and thus may both believe that the liquidity of chain C can be distributed to their users. As a result, chain B will only discover the fact that the liquidity has already been exhausted by chain A when chain B’s request is sent to chain C, where it will be rejected. And this is simply because chain B’s speed of confirming new blocks is slower than chain A’s.

• Native asset transaction: whether assets received are native. To ensure immediate consistency, some cross-chain bridges will issue bonds when the liquidity is insufficient. Take Multichain’s solution as an example: if the liquidity of the target chain is not sufficient when the user transfers USDC, Multichain will first issue 1:1 anyUSDC to the user, and perform 1:1 exchange of anyUSCD for USDC when the liquidity of the latter is sufficient. This is a paradigm of sacrificing “native asset transaction” for “instant guaranteed finality”, because it requires user’s additional layer of trust to Multichain, as well as the opportunity cost of abandoning the use of USDC to participate in DeFi when acquiring anyUSDC.

• Unified liquidity: whether the liquidity on each chain can be uniformly used. When instant guaranteed finality and native asset transaction are ensured, a liquidity pool must be built between every two blockchains if a more complex dynamic liquidity allocation algorithm is not involved. Thus, the number of pools to be built is directly proportional to the square of number of blockchains, which undoubtedly reduces the capital efficiency.

Stargate claims that its Delta Bridge possesses all the above properties without the need of making any trade-off between them. Stargate only provides one liquidity pool for each chain, and then virtually allocates the liquidity in the pool to other chains based on the pre-set weight. The allocation aligns with the following principles:

1.If there is a liquidity gap in any channel on chain A, the new liquidity will give priority to fill the gap (the _channel_here refers to the virtual liquidity pool provided by chain A to another chain).

2.If there is any surplus after filling the gap, the surplus will be allocated to each channel based on the pre-set weight.

However, note that the second principle is difficult to implement — if the user needs to transfer an asset on chain A to chain B, this request will only involve the communication between the two chains with other chains unaware of the information that “chain A has liquidity surplus at the moment”. If this information is broadcasted directly to all chains, it would cause tremendous waste of the chain resources. Therefore, Delta Bridge has designed a cache scheme to temporarily record the liquidity surplus of chain A to be allocated to other chains on its own. This cache will not be cleared until there is a transfer request from the user between chain A and another chain.

The figure above shows the status of parameters on each chain when a user transfers money from chain X to chain Y. The following parameters are stored on each chain:

• lp_x (Liquidity provided): the number of assets pledged by the user on chain X;
• a_x (Asset): the number of assets owned by the liquidity pool of chain X at the moment;
• b_xy (Balance): the liquidity allocated by chain X to chain Y
• lkb_yx (Last known balance): the currently known liquidity chain Y allocated to chain X. Note that this information needs to be transferred from chain Y to chain X and stored on the latter;
• c_xy (Credit): the assignable amount of liquidity informed by chain X to chain Y when the next transfer from chain X to chain Y occurs, which can be referred to as the “cache” mentioned above.

Delta Bridge itself is an “update mechanism for each parameter” designed to meet the “two principles” mentioned above. For a transfer from chain X to chain Y, Delta Bridge only transmits two numerical information through LayerZero: “volume of this transaction” and “cache”, with all other parameters automatically updated through Delta Bridge. Those who are interested in the detailed steps of the algorithms can probe into the .

So, can Stargate lead the new direction of cross-chain bridges with its sophisticated algorithms and schemes? Let’s take a look at the on-chain data and DeFi users’ choices.

On-chain data: can Stargate maintain a 20% APY ?

Delta Bridge’s schemes allow users to pledge a certain kind of stable currency only on a certain chain, and the early additional $STG (Stargate’s token) subsidy once made the annual pledge yield of a single type of stable currency reach 20%. This highly convenient mechanism with high rates of return quickly drew the attention of countless DeFi users and helped Stargate’s TVL reach $3.5 billion. As of the time of this writing, the APY of each Stargate’s farm is still around 17%~20%, as shown in the figure:

Take USDC on Ethereum as an example. Its liquidity is $675.5 million and its APY is 17.38%. From here, we can calculate the amount of reward allocated by the liquidity pool each day as follows:

On the other hand, we hope to calculate the daily transaction volume and daily transaction count of Stargate, so as to estimate the daily revenue of cross-chain bridges. Although Stargate does not have its own transaction browser, its official document exhibits , which allows us to count the transactions interacted with it on the blockchain and thus calculate the transaction volume and transaction count.

We accomplished this task with the help of the retrieval function on the database of Dune Analytic . Since different blockchains do not have a shared database and Dune does not include all blockchains’ databases, we decided to only use the data on Ethereum. The amount and number of daily transactions by Stargate from Ethereum are as follows, and the code is :

As is shown in the number of transactions, Stargate’s daily transaction volume is not large — on Ethereum, the number of daily transfers out is only maintained at an average of around 120. Even if we put this volume on all seven chains supported by Stargate, the 840 daily transaction volume is still far less than that of other cross-chain bridges in the market: about and about . We further discovered that the number of users adopting “Swap” in the Stargate contracts is far less than that of users using “Add Liquidity”, meaning that more users are just the DeFi miners who want head mining rather than people with real demands for cross-chain transfers.

These signs indicate that few users really use Stargate as a cross-chain solution, and the new technology of Delta Bridge is not the supporting factor of Stargate’s high TVL.

On the other hand, Stargate presented a real-time Gas Estimator on its official website, as shown below:

The estimates of gas fees obtained by Gas Estimator vary greatly at different times. Among these different fees, the gas fee of the Ethereum-to-other-chains transactions fluctuates between 20USD and 100 USD. Suppose Stargate can earn a 50-USD fee for each cross-chain transaction from Ethereum to other chains, and according to the histogram, the number of daily transactions is about 120, the daily profit of cross-chain handling fee obtained by Stargate cross-chain bridge on Ethereum would be:

Compared to the mining rewards sent out by Stargate on Ethereum, this profit is next to nothing. In fact, the ratio of commission profit to daily mining reward is:

In other words, 98.1% of the mining rewards are gained through the Stargate subsidy.

It is therefore reasonable to doubt that a high APR of more than 15% is unsustainable. If Stargate cannot attract enough users and maintain at least a few thousand transactions before the end of the generous subsidy stage, the users may not be persuaded to stick to Stargate in the long run.

Security concerns under the relay scheme

In addition to the possible loss of users caused by the unsustainability of high yield, Stargate also faces the risk from a ground level — the security concerns under the relay scheme. On March 28, 2022, the LayerZero team updated the verification contract for cross-chain use. Through the comparison of the codes, Cobo security team found that this update was a repair to the previous major security vulnerabilities: the code which revealed the vulnerability was the core verification part of the MRT transaction and the basis of the normal operation of LayerZero and its upper protocols. Cobo announced that the possibility of other vulnerabilities still exists although LayerZero has fixed the current vulnerabilities. As the first “superstructure” to ever use the LayerZero protocol as of March 28th, Stargate may face unimaginable consequences if its huge amount of funds in the liquidity pool were transferred by hackers.

Ronin, the side chain of Axie Infinity at the other end of the blockchain world, was not so lucky. On March 29, 2022, Ronin’s cross-chain bridges were attacked by hackers, resulting in . At present, Ronin’s chains are composed of nine verification nodes which require five of the nine verifiers’ signatures to identify deposits or withdrawals. The hackers managed to control four validators of Ronin and one third-party validator run by Axie DAO.

As we can see, in the “relay” scheme, the existence of the relayer may bring potential security vulnerabilities. In the “witness” scheme represented by Ronin, even more security vulnerabilities exist — a fact that has been confirmed by the frequent hacking incidents in Multichain, O3 Swap, and Wormhole in the past two years. Meanwhile, few security problems appear in cross-chain bridges with HTLC schemes such as cBridge, Hop finance and Meson. The fundamental reason HTLC schemes have fewer security problems compared to the previous two schemes is that users do not have trust costs to third parties, including large enterprises, developers, institutions, and exchanges. We hope to see more innovations like the HTLC scheme in the blockchain world to address the root cause of these trust issues.

In this era where fierce competition between multi-blockchains increases, cross-chain bridges have become an essential infrastructure. In the future, we hope to see more healthy competition between cross-chain bridges, putting the security of users’ assets first rather than simply pursuing a temporary hotspot in the market, as countless previous projects have proved to us that only those who are most in line with the spirit of decentralization can be prosperous in the long run in the blockchain world where code is law is the totem.

Also Published

Twitter @crosschaingeek

Medium @crosschaingeek