Author: Arjun Chand, researcher at LI.FI; Translated by: Golden Finance xiaozou
Key points of this article
●Solana ecosystem bridging activity has increased significantly, especially since November 2023. Bridges such as Wormhole, Allbridge, and deBridge (early supporters of the Solana ecosystem) stand a good chance of benefiting from this surge.
●User demand to transfer funds to Solana has triggered a boom in the expansion of liquidity bridges to Solana. In December alone, Synapse, Meson, and Hashflow added path support to Solana. Soon, the need for aggregation platforms like Jumper to support Solana will become apparent.
● When it comes to messaging protocols, Wormhole provides developers with the most powerful tools, while deBridge’s DLN is becoming the liquidity bridge of choice for asset transfers.
●There are few apps on Solana with built-in bridging capabilities, but that is changing. Phantom and Jupiter are at the forefront of this evolution, embedding bridging capabilities into their services.
●Upcoming projects—such as Circle’s CCTP, Wormhole’s Cross-Chain Queries (cross-chain queries), and Jumper Exchange’s Cross-Chain Swaps (cross-chain exchanges)—will enhance Solana’s engagement with the broader blockchain ecosystem Connection. Additionally, innovations such as Tinydancer’s light client and Picasso’s IBC Guest blockchain concept promise to enable trust-minimized cross-chain interactions.
Preface
Discussions surrounding Solana are becoming more and more lively, and there are more and more activities in the Solana ecosystem. Of course, more and more developers and users want to interact with the ecosystem. Now is the perfect time to take a deep dive into bridging Solana.
This article is the definitive resource for anyone interested in learning about Solana. This article aims to fulfill the intentions of two main groups: developers who are eager to build cross-chain applications using messaging protocols, and users who are transferring assets to Solana in search of the next thousand-fold growth meme coin. Hopefully this article can help them achieve their goals. Tickets to the best wishes for early retirement.
This article is mainly divided into three parts:
Part One: A Deeper Look at Messaging Protocols on Solana – This part will analyze the messaging protocols currently running on the Solana ecosystem. We'll examine the technical input, operating mechanisms, and inherent trade-offs associated with these protocols, with the goal of providing developers with key information to help them choose a messaging protocol that meets the needs of their applications, as well as providing information for those interested in learning more about the applications they use. Users of the program provide information about its origin, functionality and safety.
Part 2: Applications that support Solana cross-chain exchange - The second part of this article will explore the various applications that support Solana bridging and cross-chain exchange. We’ll discuss how these applications work, their best features, impact on user experience, and how they contribute to the liquidity and accessibility of the Solana ecosystem.
Part 3: Interesting Developments in the Solana Interop Scenario - The final part will highlight the most noteworthy recent developments in the Solana interoperability scenario and will cover new projects, interesting new versions of existing protocols, and other developments that can positively impact Solana's future and Initiatives in the way the broader blockchain ecosystem interacts.
Next, let us look at each part in detail.
1. In-depth understanding of the messaging protocol on Solana
This section examines the design, security, and trust assumptions of the various messaging protocols that connect Solana to the broader ecosystem. It provides a comprehensive analysis of their architecture, highlights their unique features, and understands their trade-offs.
This section will cover the following:
●Messaging Protocol Overview: An in-depth look at the project’s product suite, performance data, key network effects, and security information.
● How it works: Transaction lifecycle – the process of sending user funds from one blockchain to another through a liquidity network built on a messaging protocol. Learn about the different components of a bridge design.
●Trust assumptions and trade-offs: The trade-offs of each messaging protocol and their potential impact.
●Risk analysis: architectural design and security considerations - summarize the architecture, implementation, operation and network security of the messaging protocol based on the cross-chain risk framework jointly developed by LI.FI and Consensys.
●Community and Resources: All resources to track updates on the project and learn more about its products and services.
1.1 Wormhole
1.1.1 Overview
Wormhole is a messaging protocol launched in October 2020 to enable developers to build cross-chain native applications across multiple chains. Wormhole originally originated as a hackathon project to find a solution that would allow blockchains to "talk to each other."
Wormhole was originally incubated and supported by Jump, and its first version (Wormhole V1) was mainly focused on establishing a two-way token bridge between Ethereum and Solana. As the project progressed, Wormhole evolved into a universal messaging protocol, connecting multiple chains in the ecosystem. This evolution is in line with its broader vision to become the base layer on which developers can build a variety of cross-chain applications. As a result, Wormhole V1 was gradually phased out, and the Wormhole network was launched in August 2021.
product service
In response to the growing demand for multi-chain ecosystems, several cross-chain native applications have emerged on top of Wormhole, including the Wormhole team’s own products:
●Portal — A token locking and minting bridge that allows users to bridge tokens and NFTs on Wormhole compatible chains. It was one of the first applications to use Wormhole's messaging capabilities and made a significant contribution to the development of Wormhole.
●Connect — A gadget that allows developers to integrate a Portal-like interface into their applications to bridge tokens. It provides developers with a simple and fast way to add bridging functionality to their applications.
●Gateway — an application-specific blockchain designed to improve the connection of Cosmos-based application chains to the broader ecosystem. It uses a liquidity router as a unified liquidity layer across Cosmos chains. This tool is beneficial for developers aiming to attract users and liquidity to the Cosmos AppChain, as well as users seeking to transfer funds to the Cosmos ecosystem. Gateway is currently available to developers and to users via the Portal.
●Queries — Tools for cross-chain data querying, enabling applications to read on-chain data from any EVM chain within the Wormhole ecosystem. This data was verified by a 2/3 absolute majority of 19 Wormhole Guardians. The product is still in the early stages of development, and Synthetix is expected to be an early adopter.
These products are further supported by multiple developer-friendly solutions and features from the Wormhole team (many of which are now developed and maintained by contributors to the newly formed Wormhole Foundation), such as:
●xAssets — Assets can be bridged across any Wormhole supported chain without slippage. For example: Pyth Network recently launched their PYTH governance token as a Wormhole xAsset, available to users of 27 chains.
●Automatic Relayers — A network of relayers that can pass messages across any Wormhole supported chain. This feature allows developers to build cross-chain applications on Wormhole without having to set up and maintain their own off-chain relayer.
●Wormholescan — a cross-chain block browser and analysis platform covering the Wormhole ecosystem. This tool can be used to track cross-chain transactions and understand network activity across the Wormhole ecosystem.
network effect
Considering Wormhole’s early development and continued focus on the Solana ecosystem, it’s no surprise that Solana is the most active chain on Wormhole in terms of transaction volume.
Interestingly, Wormhole’s traffic data is dominated by bridge traffic to and from Terra, an ecosystem that no longer sees any significant progress and activity. Currently, transaction volume is mainly distributed in Ethereum, Solana, and Sui, followed by EVM L1 chain and rollup.
Factors that have fueled Wormhole’s growth and positioned it as one of the top messaging protocols in the ecosystem include the following:
● 200+ projects built on Wormhole — Wormhole has established a significant distribution in the ecosystem, with several applications using it to build use cases such as liquidity bridges (Allbridge, Mayan, Magpie), multi-chain tokens ( PYTH), token standards (Nexa), in-app bridging using Connect (Astroport, Uniwhale, YouSUI), cross-chain deposits (Friktion, PsyOptions, Aftermath Finance).
●Wormhole x NFT — Wormhole’s cross-chain NFT standard is favored by Dust Labs for migrating their NFT series (DeGods and y00ts) from Solana to Ethereum and Polygon respectively. This NFT standard is also used by the Aptos NFT Bridge, which enables developers and users to bridge NFTs to and from the Aptos network.
●Wormhole’s $50M Ecosystem Fund — The $50M Ecosystem Fund provides much-needed financial support to developers building cross-chain applications that leverage Wormhole’s messaging infrastructure. The fund is managed and operated by Borderless Capital and has received financing support from well-known investors such as Jump Crypto, Polygon Ventures and the Solana Foundation.
●xGrant Program — In early 2023, Wormhole launched the xGrant program to provide support to developers, researchers, and founders. The program not only provides financial assistance, but also provides guidance and resources to promote the development of innovative projects. Grants cover expenses such as software development, marketing, team costs, and other expenses needed for the program to grow and expand.
●Bitcoin tBTC on Solana — Threshold Network has launched tokenized Bitcoin (tBTC) on Solana, using Wormhole to mint the asset. This marks tBTC’s first expansion into the non-EVM ecosystem and enables users to spend Bitcoin in the Solana DeFi ecosystem.
●Wormhole joins hands with Uniswap — After a comprehensive evaluation of 6 different bridges, Uniswap’s Bridge Evaluation Committee approved the use of Wormhole for all cross-chain deployments, which greatly enhances Wormhole’s status as one of the most secure messaging protocols in the ecosystem . Additionally, Uniswap actively uses Wormhole for cross-chain messaging (particularly chains like Celo), which further solidifies Wormhole as a reliable choice for secure messaging needs.
●Wormhole joins hands with Circle CCTP — Wormhole has successfully integrated Circle’s Cross-Chain Transfer Protocol (CCTP) so that other applications can access it through Connect and users can also access it through Portal. The anticipated release of CCTP on Solana has generated significant interest, and teams such as Jupiter have announced plans to provide support for CCTP within their applications via Wormhole.
●Wormhole raised US$225 million in financing, with a valuation of US$2.5 billion - Wormhole recently reached an important financing milestone, completing US$225 million in financing, with a valuation of US$2.5 billion. This significant investment highlights the strength of Wormhole’s team, the widespread adoption of its products and services, and the overall quality of its products and services. The funding has also attracted the attention of airdrop farmers, who are now comparing Wormhole closely to LayerZero and consider Wormhole to be "a highly valuable competitor in the interoperability space." As the Solana airdrop season continues and Wormhole launches various strategic initiatives (such as providing "early" roles for Discord users, this may attract a lot of attention from airdrop farmers in the near future).
Security check
●Audit—The Wormhole architecture consists of several key parts, such as Guardian nodes and smart contracts for different chains and execution environments. Various parts of their technology stack have undergone a total of 22 audits by Neodyme, Kudelski, Trail of Bits, CertiK, Runtime Verification, OtterSec and Zellic. It is worth noting that while we treat each entry as a separate audit, it is likely that the audit of these specific contracts is part of some larger audit of the Wormhole technology stack.
●Bounty program — Since September 2022, Wormhole has been running a $2.5 million bounty program on Immunefi, focusing on the security of Wormhole smart contracts and Guardian nodes.
●Security vulnerability - In February 2022, the Wormhole network experienced a security vulnerability. The attacker "exploited a signature verification vulnerability in the Wormhole network to mint 120,000 Wormhole wrapped Ethereum coins on Solana", causing losses estimated to be approximately 326 million Dollar. The vulnerability was patched within hours, Wormhole was quickly back online, and Jump provided the necessary funds to close the gap.
Following this exploit, the Wormhole team announced the following future security plans:
●Continuous auditing - Conducted a comprehensive and ongoing audit of the Wormhole code base and made plans to prevent future vulnerabilities.
●Advanced Monitoring Tools—Ensure successful dynamic risk management with features such as accounting mechanisms and monitoring tools to isolate cross-chain risks and detect threats early.
●Bug Bounty Program — Wormhole launched a bug bounty program on Immunefi, which was launched shortly after this vulnerability attack.
In light of these security upgrades, Uniswap’s Bridge Evaluation Committee recognized Wormhole’s efforts in their report, stating:
"Following the vulnerability attack, Wormhole made substantial improvements to its practices, such as improved deployment processes, a clearer incident response plan, and robust unit testing. These improvements are commendable and demonstrate the growth and maturity of the protocol."
Wormhole has added the following security features to its technology stack:
●Global accountant — This tool monitors the total circulating supply of all Wormhole assets across all chains. Essentially, it prevents any blockchain from transferring any assets beyond what is actually allowed.
●Governor (Manager) - As a supplement to global accounting, the Governor tracks the inflow and outflow of all on-chain assets. It has the power to delay suspicious transmissions and limit the impact of exploits by allowing Guardians to retain Wormhole messages for 24 hours if they become too large. Governor's limits can be adjusted as the chain ecosystem matures.
● Open Source Code Base — By making its code base open source, Wormhole effectively lowers the barrier for white hat hackers to identify and report vulnerabilities.
●Comprehensive monitoring through Guardians — Wormhole Guardians are professional verification companies with expertise in running, monitoring, and securing blockchain operations. They continuously track blockchain and smart contract activity and ensure the security of the Wormhole network through tools such as Governor.
●ZK (zero-knowledge proof) integration with Wormhole — Wormhole is actively integrating message ZK verification into its technology stack.
growth data
1.1.2 How it works—Transaction life cycle
The process of transmitting messages from the source chain to the target chain through Wormhole's architecture is very complex, but at a high level it is very straightforward. Here is a simple exploded view:
1) Sending a message: Each message comes from a "core contract" on the source chain.
2) Guardians Verification and Signing: The message is then verified and signed off-chain by 19 Guardians. A message is considered authentic only if it receives signatures from at least two-thirds (13 of 19 Guardians).
3) Forward to the target chain: Once the message is verified and signed, it will be forwarded to the core contract on the target chain.
Looking more closely, we see that there are several key components that work together to ensure secure cross-chain messaging:
Let’s take a deeper look at how the Wormhole Guardian network verifies messages:
Step one: The core contract on the source chain sends a message.
Step 2: Guardians observe and verify the authenticity of the message.
Step 3: Guardians wait for the source chain to finally confirm the message, and then sign the hash value of the message body to prove its validity.
Step 4: Compile the signatures of each Guardian into a multi-signature file, namely VAA (Verifiable Action Approvals).
Step 5: Relayers transmit VAA to the core contract on the target chain.
Note: "Spy" monitors all messages transmitted through the Guardian network and logs them in a storage system (such as a SQL database) for analysis and further use.
1.1.3 Trust assumptions and trade-offs
Here are some trust assumptions and trade-offs worth noting about Wormhole:
●External verification by a set of validators — Wormhole’s Proof of Authority system believes from beginning to end that Guardians can be trusted to verify transactions, and that more than two-thirds of Guardians will not collude within a specific time. If a majority of Guardians collude with each other, user funds can be stolen.
●Censorship risk—Guardians on 7/19 may collude to censor messages.
●No slashing mechanism for Guardians - In the Wormhole system, there is no slashing mechanism for Guardians. However, accountability is a key aspect of network design. Any malicious activity can be directly traced to a specific Guardian. This direct attribution means that following the occurrence of fraud or misconduct, the Guardian involved could face legal liability and suffer significant reputational harm.
●Permissioned Guardian Network—Adjustments to the Guardian set, whether adding new Guardians or removing existing Guardians, are governed by the 13/19 signature scheme.
1.1.4 Risk Analysis: Architecture Design and Security Considerations
1.1.5 Community and resources
You can learn more about Wormhole through the following channels:
●Official website
●Documentation
●Wormhole for developers
●Github
●Explorer
●Medium
●Wormhole Scan
You can follow Wormhole on the following platforms to learn about the latest developments in its community:
●Discord
●Telegram
●Youtube
1.2 Allbridge
1.2.1 Overview
Released in July 2021, Allbridge is a blockchain bridge within the Solana ecosystem. It was originally named Solbridge because when it was first released its focus was on expanding the use of Solana in the ecosystem by connecting Solana to other chains. Over time, the scope of the protocol expanded beyond Solana and was renamed Allbridge.
product service
Allbridge Classic is the first version of Allbridge. It supports asset transfer across 20 chains, including EVM and non-EVM chains such as Solana and Stellar. This version of the protocol is responsible for handling the majority of Allbridge’s transaction volume.
In June 2022, Allbridge launched Allbridge Core, a new-age bridging platform focused on cross-chain stablecoin exchange. This new version solves the pain points of the old version, the most prominent of which is the multi-step and time-consuming process of deploying bridge tokens packaged by Allbridge and redeeming them for the required assets.
Allbridge Core simplifies the bridging experience by focusing on stablecoin exchange. Since most bridging activity involves stablecoins, Allbridge Core is able to meet the needs of most users while maintaining the simplicity and lightweight nature of the product. Currently, Allbridge Core has 11 liquidity pools, enabling stablecoin exchange across 7 chains.
Additionally, Allbridge Core introduces unique features such as:
●Support multiple message protocols - In addition to supporting cross-chain message transmission through Allbridge, Allbridge Core also supports other message protocols, such as Wormhole. Such integration enables it to support unique chains accessible through Wormhole and provides alternative/fallback options to chains already supported by Allbridge.
Additionally, Allbridge Core recently integrated Circle’s Cross-Chain Transfer Protocol (CCTP). This new addition enables Allbridge Core to support USDC transfers across CCTP-compatible chains without the need to maintain liquidity pools on those chains. In addition, users can choose between three different messaging protocols, each with different transmission costs and times.
Currently, CCTP support is only available on the EVM chain. However, this will soon change as CCTP has supported Solana on the devnet and will be coming to mainnet in the near future.
●Extra gas on the target chain — This feature solves the "cold start" problem when users bridge assets to a new chain. With this feature, users can easily bridge some additional funds to pay gas fees on the target chain.
The “extra gas” feature is slowly becoming a standard in multi-chain ecosystems. For example, in the Solana ecosystem, Phantom is used as a "refueling" function for the "Cross-Chain Swapper" by integrating with LI.FI (powered by Allbridge Core).
In addition to user-facing products such as Allbridge Classic and Allbridge Core, Allbridge also offers a white-label bridging solution called Allbridge BaaS. This allows projects to use Allbridge’s cross-chain messaging capabilities and launch dedicated bridge setups for their tokens. Allbridge will charge a one-time bridge setup fee of $20,000.
network effect
From its initial product focus on Solana to winning the Solana Hackathon in 2021, Allbridge's roots are deeply connected to the Solana ecosystem. Focusing on Solana has proven to be beneficial, and Solana is still the most active chain on Allbridge. Since its launch, Allbridge Classic has conducted more than 190,000 transactions on Solana, with a transaction volume exceeding US$1.44 billion, and generated US$535,000 in fees on Allbridge Classic alone.
Other major ecosystems fueling Allbridge’s growth include names that are well-known across all bridge platforms, such as Ethereum, Avalanche, BNB Chain, and Polygon. Interestingly, the Tron network is a compelling ecosystem as far as Allbridge Core is concerned.
It’s worth noting that popular L2 solutions such as Arbitrum and Optimism, which often dominate EVM bridge metrics, are absent from the above list. It is worth mentioning that Allbridge does not provide support for several major emerging L2s, such as Base, zkSync and Linea. Allbridge Core only supports USDC on Arbitrum.
Recently, Allbridge Core integrated with LI.FI, entering the world of LI.FI’s more than 120 cross-chain exchange protocols. Additionally, Allbridge is currently the only bridge provider to support EVM <> Solana transactions in the Phantom Cross-Chain Swapper feature. This exclusivity allows Allbridge to benefit from larger transaction volumes until support for other bridge providers is added.
In addition, Allbridge also conducted a CCTP integrated test network demo display at the Breakpoint 2023 conference. A strategic partnership with Circle to launch CCTP on Solana will also benefit the protocol’s growth.
Security check
●Audit - Allbridge's architecture has been audited 5 times. They are the first audit conducted by Hacken in September 2021 (audit score: 10 points), the audit by Kudelski Security in May 2022, the audit by Cossack Labs in September 2022, and the audit by Hacken in February 2022 (audit score: 9.8 ), and CoinFabric’s audit in July 2023.
●Bounty Program — Allbridge has an open bounty program on HackenProof, with reward amounts ranging from $100 to $4,000.
●Security vulnerability - In April 2023, due to a flash loan vulnerability on the BNB chain, Allbridge Core suffered a security vulnerability attack, resulting in a loss of US$650,000. The attacker exploited a logic flaw in the withdrawal functionality to manipulate the pool's trading price.
The Allbridge team recovered "most of the stolen funds" and reimbursed the difference to affected users who filled out the application form. After the attack, the protocol was restarted, the following fixes were made, and the following security features were added:
●Corrected liquidity calculations for deposits and withdrawals – extensively tested.
●Introducing Rebalancer permissions via special accounts — This tool will allow teams to rebalance pools in extreme and emergency situations by using bridges without paying fees.
●Automatic shutdown function in case of extreme pool imbalance, such as stablecoin decoupling.
●Support manual closing of the bridge to improve response time to prevent accidents.
●A public code base that highlights the team’s open source efforts and invites white hat researchers to conduct bridge contract reviews.
The L2BEAT team stated that Allbridge Core “contains many unverified core smart contracts” that could put user funds at risk if these contracts contain malicious code.
It is worth noting that after the security vulnerability attack, Allbridge Core’s contract was redeployed. The main contract is now verified. Additionally, the Allbridge Classic contract has been verified.
However, the L2BEAT team noted that some bridge contracts are still unverified. The Allbridge team explained that this was a complex issue caused by the overlap between the old Core contract and the Allbridge Classic-related contract that existed before the security incident. Allbridge is actively taking steps to address and clarify this discrepancy on the L2BEAT website, ensuring a clearer and more transparent understanding for all.
growth data
1.2.2 How it works—Transaction life cycle
Allbridge Core
Here’s how assets are transferred from the source chain to the target chain through the Allbridge Core architecture:
Step 1: The user sends the asset to the liquidity pool on the source chain, where the asset is locked.
Step Two: Exchange these assets into Virtual Tokens (VT) that represent their USD value. For example, when a user sends 100 USDC, the amount is converted to VT based on the current VT to USDC exchange rate.
Step 3: Transfer virtual tokens with transaction information to the target chain via the chosen messaging protocol. The messaging protocol's validator verifies that funds have been locked on the source chain and accurately redeemed for "virtual tokens."
Step 4: The message reaches the target chain and triggers the smart contract.
Step 5: The smart contract converts the virtual tokens in the liquidity pool on the target chain into the tokens you want to exchange, and sends them to the user's address.
While this may seem like different steps on different chains, to the user it all happens in one click.
Allbridge Classic
Allbridge Classic supports a wide range of tokens such as aeUSDC (Allbridge Ethereum wrapped USDC), minted by Allbridge Bridge.
The following is the process of asset transfer from the source chain to the target chain through the Allbridge Classic architecture:
Step 1: The user sends funds to the Allbridge smart contract on the source chain. In this step, users can send two types of assets: 1) Local assets — in this case, the assets are locked in a liquidity pool on the source chain. 2) Wrapped assets — In this case, the assets are destroyed by smart contracts on the source chain.
Step 2: Create a transaction record and send a verification request to Allbridge validators.
Step 3: Validators verify the funds locked on the source chain.
Step 4: Once verification is complete, validators release the signature to the user.
Step 5: The user forwards this signature to the smart contract on the target chain.
Step 6: The funds are transferred to the user. The process will vary depending on the type of asset the user expects to receive on the target chain.
Specific examples are as follows:
1) If they are native assets, then these assets will be unlocked from the smart contract of the target chain and then transferred to the user's wallet.
2) In the case of wrapped assets, these assets will be minted by smart contracts on the target chain and then transferred to the user's wallet.
1.2.3 Trust assumptions and trade-offs
Here are some noteworthy trust assumptions and trade-offs about Allbridge:
●External verification by a set of validators - Allbridge relies on third-party validators to verify users' transactions, which depends on the underlying messaging protocol used (Allbridge or Wormhole or CCTP).
●Small validator set - Allbridge's validator set contains only 2 validators. These two validators may collude to deliver malicious messages and steal user funds.
●Censorship risk - A single validator in Allbridge's validator set can censor messages.
●Permissioned validator set - The validators running in the system are run and/or selected by the Allbridge team.
●No slashing mechanism - There is currently no slashing mechanism for validators to prevent collusion or censorship.
●The Allbridge team can censor users — While a special account will give the Allbridge team more control to respond quickly in emergencies, it can also be abused to mistakenly censor a user’s deposits, withdrawals, and transactions.
1.2.4 Risk Analysis: Architecture Design and Security Considerations
1.2.5 Community and Resources
You can learn more about Allbridge through the following channels:
●Official website
●Allbridge Core file
●Allbridge Classic files
●Medium
●Messari on Allbridge Core
●Messari on Allbridge Classic
You can follow Allbridge on the following platforms to learn about the latest developments in its community:
●Telegram
●Discord
1.3 deBridge
1.3.1 Overview
deBridge is an interoperability protocol released in August 2021 that supports cross-chain messaging and liquidity. The project launched as a hackathon project at the Chainlink Global hackathon in April 2021 and received $5.5 million in financing later that year.
deBridge’s expansion into the Solana ecosystem began with a $20,000 grant from the Solana Foundation in June 2021. Unlike the previously discussed protocols, deBridge was originally targeted specifically at EVM-compatible chains. It was not until June 2023 that deBridge came to Solana and became one of the early participants who made great achievements.
product service
deBridge’s product suite includes a range of cross-chain applications that leverage its messaging capabilities:
●deSwap Liquidity Network (DLN) — DLN is a liquidity network that enables low-cost and fast cross-chain transactions on any chain supported by deBridge. Unlike traditional models that rely on liquidity pools, DLN utilizes market makers that provide cross-chain liquidity on demand to achieve zero TVL asset transfers. In order to ensure sufficient liquidity for large cross-chain orders, the deBridge team cooperates with mature market makers such as RockawayX and Fordefi.
●dePort — As a lock-and-mint bridge, dePort allows applications to create debridge-wrapped assets, or deAssets, on each chain. These minted assets are backed one-to-one by the original tokens on the source chain, ensuring the integrity of the entire network’s assets.
In addition to user applications directly for cross-chain exchange, deBridge also extends these products to other applications and projects, including wallets, through APIs for seamless integration. Additionally, bloXroute Labs is developing an SDK with the goal of integrating DLN into their blockchain distribution network. This integration will enable bloXroute users, including MEV hunters, institutional DeFi traders, and various projects, to perform DLN-powered cross-chain swaps.
In addition, deBridge also offers deBridge IaaS (Interoperability-as-a-Service: Interoperability as a Service), a subscription-based service that enables EVM and SVM blockchains to integrate deBridge products into their respective ecosystems . The service has a monthly subscription fee of $11,000 per month and a quarterly subscription fee of $10,000 per month. Neon Labs is the first user of the service.
network effect
Since its launch, deBridge has experienced steady and continued growth. The protocol has seen a surge in usage recently, especially on Solana. Solana <> The Ethereum path has quickly become the most crowded corridor on the DLN. The deBridge team’s strategic move to allocate resources to integrate Solana support is clearly paying off, and the potential for future growth is huge.
DLN’s near-instant cross-chain order settlement capabilities have quickly made it the platform of choice for users looking to transition to Solana from other blockchains. Recently, DLN reached a major milestone, surpassing $10 million in daily trading volume for the first time – a testament to its growing popularity, and this achievement may be just the beginning as the Solana ecosystem accelerates.
In addition to individual users, deBridge is also becoming more and more popular in the B2B field, and more and more applications on Solana integrate deBridge's services into their own products. The most notable examples include MoonGate, Birdeye, and Jupiter bridge comparator tools.
This trend suggests that deBridge is strategically positioned to capitalize on the expansion of the Solana ecosystem during the upcoming next cycle.
Security check
●Audits — deBridge has demonstrated its strong commitment to security, with smart contracts on the EVM chain and Solana successfully undergoing 15 comprehensive audits. These audits are conducted by well-known security companies, including Halborn, Neodyme, Zokyo, and Ackee.
●Bounty Program — Since January 2022, deBridge has run a $200,000 bounty program on Immunefi focused on ensuring the security of its smart contracts.
growth data
In the fourth quarter of 2023, DLN performed prominently among liquidity networks, strikingly similar to the growth trajectory of TVL and transaction volume of the Solana ecosystem during the same period.
To understand how DLN performed in the final quarter, here's a quick look at its fourth-quarter results versus its cumulative results for the full year 2023 (April 1, 2023, to December 31, 2023):
1.3.2 How it works—Transaction life cycle
The following shows how assets are transferred from the source chain to the target chain in a cross-DLN transaction:
Step 1: The user (i.e. Maker) initiates an order on the source chain. This is done by calling the DlnSource.createOrder() function, where they provide the transaction details and lock the input token in the contract.
Step 2: Market makers, also known as Takers, monitor these off-chain orders. When they identify an order that matches their criteria such as profitability and token availability, they will fulfill that order. This is achieved by executing the DlnDestination.fulfillOrder() function on the target chain, where they provide the token specified by the Maker request.
Step 3: After receiving the order, DlnDestination verifies the details and completes the transaction by sending the tokens to the recipient address on the destination chain. The order is then marked as Completed.
Step 4: The Taker who completes the order then calls the DlnDestination.sendunlock() function. This action triggers a cross-chain message through deBridge’s infrastructure to the DlnSource smart contract located on the source chain.
Step 5: DlnSource confirms the authenticity of the message and releases the previously locked input tokens, transferring them to the Taker who fulfills the order.
1.3.3 Trust assumptions and trade-offs
deBridge, like all interoperability protocols, operates under certain trust assumptions and trade-offs, of which users should be aware:
●External verification by a set of validators — The deBridge network is secured by a relatively small set of validators consisting of 11 nodes. To confirm a transaction, it requires signatures from at least two-thirds of the validators, that is, at least 8 out of 11 validators must sign. This structure introduces the risk that eight validators may collude to endanger the security of user funds.
●Censorship risk - If a small number of validators (especially 5 out of 11 validators) decide to collude, there is a potential censorship risk. This may result in intentional blocking or delay of message delivery.
● No slashing mechanism for validators — Although deBridge’s documentation cites future implementation of delegated staking and slashing mechanisms as key to the protocol’s security, these features have not yet been launched. Without slashing, there is no direct financial consequence to prevent the validator from engaging in fraudulent or malicious behavior. However, it is important to note that the current set of validators were selected and authorized by the deBridge team and are pre-existing entities that are at risk of legal action and reputational damage, which may serve as an indirect form of accountability.
●The target token contract can be maliciously upgraded by validators - L2BEAT stated that the management of all upgradable proxy smart contracts is a Gnosis Safe with a 5/8 threshold. Therefore, if the target token contract is maliciously upgraded or not deployed securely, user funds may be stolen.
Note: It is important to note that deBridge is on the road to decentralization. The issues mentioned above, such as the lack of a slashing mechanism and the permissioned nature of the validator set, are expected to be resolved with the launch of deBridge’s native token, which will enhance the economic security and governance of the protocol.
1.3.4 Risk Analysis: Architecture Design and Security Considerations
1.3.5 Community and resources
You can learn more about deBridge at:
●Official website
●Documentation
●DLN document
●deExplorer
●Github
●Medium
●Blog
You can learn about the latest developments in its community through the following platforms:
●Discord
●Telegram
1.4 Comparative analysis of messaging protocols and their liquidity networks
After analyzing the design and characteristics of different messaging protocols, we will now summarize their architecture and deployment security. Our goal is to quickly compare the security considerations associated with different messaging protocols and enable developers to choose based on their preferred trade-offs and security guarantees.
In the specific analysis, we will see the comparison based on the following indicators:
●Consensus mechanism—How does the protocol determine the validity of the message?
●Validator set collusion - the minimum number of validators that can collude to steal funds.
● Censorship Resistance – The minimum number of signers that can censor messages passing through the protocol.
● License-free feature - Is the validator set license-free? Can anyone become a validator and contribute to determining the validity of messages?
●Slashing Mechanism - Is there an active slashing or binding mechanism to prevent malicious behavior of validators?
●Upgradability of smart contracts - Are the smart contracts of the protocol upgradable? If upgradeable, who will upgrade?
●Bug Bounty—The maximum amount of bug bounty that can be obtained by white hat hackers who discover critical vulnerabilities in the protocol code.
●Audit—The number of audits each protocol has undergone (the more, the better).
Here is a comparison of messaging protocols on Solana:
Next, we will analyze the performance of each liquidity network before December 31, 2023, and look specifically at three key indicators:
●Unique users — How many unique users have used the liquidity network since launch?
● Number of transactions — How many transactions have been executed using the liquidity network since launch?
●Bridge volume — How much volume has passed through the liquidity network since launch?
Here is a performance comparison of liquidity networks built on messaging protocols:
2. Applications that support Solana cross-chain exchange
Building on the previous installment’s exploration of various messaging protocols and their developers’ potential to create cross-chain applications, we now turn our attention to one of their most prominent uses: liquidity networks. This section will focus on the various liquidity networks that connect Solana to the broader ecosystem, helping users easily move funds across chains.
Additionally, we’ll look at some of the interesting apps and features being launched around liquidity aggregation that are designed to make it easier for users to find the best liquidity network for their needs.
Our goal is to help users make better choices when exchanging assets between the Solana and EVM ecosystems.
let's start!
2.1 DLN (deSwap Liquidity Network)
2.1.1 Overview
DLN is a cross-chain trading protocol powered by deBridge that facilitates the creation and fulfillment of cross-chain orders.
The protocol architecture mainly has two layers: protocol layer and infrastructure layer.
Protocol layer — This layer consists of smart contracts deployed on each compatible chain. These contracts allow market participants to interact in a decentralized environment, enabling them to create, monitor and settle orders:
●Makers refer to users who create orders by locking input tokens in the DlnSource smart contract on the source chain.
●Takers refer to market makers who fulfill orders by providing output tokens to the DlnDestination contract on the target chain.
Once the order is completed, the DlnDestination contract communicates with the DlnSource contract through the infrastructure layer. This process releases the input tokens and transfers them to Taker, and the cross-chain transaction is completed.
Infrastructure layer — This layer handles cross-chain messaging through deBridge validators. It enables the DlnDestination contract to reliably communicate the fulfillment of the order to the DlnSource contract, thereby completing settlement.
2.1.2 Best Features
●Zero Slippage for All Order Sizes — Trading on DLN has zero slippage, meaning users get the price they expect regardless of order size. This feature effectively solves the slippage problem associated with traditional liquidity pools.
● Fast settlement — Due to DLN’s asynchronous design and the ability to tap market maker liquidity on demand, trades on DLN settle much faster than traditional liquidity bridges.
● Fast scalability — DLN’s design allows it to handle large volumes of transactions because it is not limited by liquidity pool or bridge throughput. Over the past month, DLN’s trading volume has been growing steadily.
Note: The minimum charge per transaction on DLN is 8 bps. This fee is split equally between the DLN protocol and the Taker completing the order, with each receiving 4 bps. However, if a user places a limit order, the fee assigned to the Taker who completes the order may exceed 4bps.
2.2 Portal
2.2.1 Overview
Portal is powered by Wormhole and is part of the Wormhole network, facilitating the transfer of assets between blockchains.
Portal Bridge is designed to enable secure and seamless transfer of fungible and non-fungible tokens across blockchains.
When an asset passes through the Portal, the original token is locked in a smart contract on the source chain, while a new Portal-wrapped counterpart is created on the target chain. This equivalent can be redeemed for other native tokens available on the chain.
2.2.2 Best features
●Access to Multiple Ecosystems — Users can move assets between the many different ecosystems and markets supported by Wormhole. This expands the scope and utility of user assets.
●Security — Wormhole’s Guardian node network and signed messages provide a reliable security model to verify cross-chain transactions. Additionally, updates and upgrades to Wormhole are transparently managed through the Guardian Network’s on-chain governance.
2.3 Mayan Finance
2.3.1 Overview
Mayan Finance is a cross-chain exchange protocol powered by Wormhole that allows users to swap tokens between different blockchains with a single click.
Currently, Mayan supports token swaps between Ethereum, Solana, Avalanche, and Polygon networks. However, the protocol plans to expand to support more blockchains in the future.
2.3.2 Best Features
● Cross-chain exchange — Mayan allows users to exchange tokens on one blockchain for tokens on another compatible blockchain through a single transaction.
●British auction mechanism—Mayan uses the British auction mechanism to promote cross-chain transactions. When a user initiates a swap, Mayan holds an auction on the target blockchain to obtain the best swap rate. This ensures the user gets the highest bid for their order.
●Token support — Mayan currently supports many ERC-20 and SPL tokens, with plans to add support for more tokens and blockchains.
●Integration tools - Mayan provides integration tools, such as SDKs and widgets, allowing other applications to embed Mayan's exchange functionality directly into their own platforms. This enables any project to provide cross-chain token exchange services through Mayan’s infrastructure.
2.3.3 Principle of Operation—Transaction Life Cycle
Step 1: Initiate an exchange on the source chain
The user initiates the process on the source chain by interacting with Mayan Swap Bridge. They initiate a cross-chain swap and set the parameters of the auction, including minimum output and deadline.
Step Two: Auction on Solana
The transaction is then moved to Solana, where it is auctioned. The winner of the auction is responsible for executing the transaction on the Solana network.
Step 3: Receive assets on the target chain
Finally, the user receives the native assets on the target chain. These assets are sent along with a specified amount of gas required for the transaction.
Assets are exchanged between different blockchain networks, using the Solana network as an intermediary auction platform. Solana's Mayan program handles the auction and swap mechanism, while the Mayan Swap Bridge is an Ethereum Virtual Machine (EVM)-compatible link for initiating and completing swaps. The destination can be another EVM chain or even the Solana chain itself.
Note: Users need to pay relayer fees, including gas fees and relayer fees for forwarding transactions for users. This fee changes based on the asset and the dynamics of the chain. If the transaction fails, the relayer fee will be significantly reduced.
2.4 Mason
2.4.1 Overview
Meson Finance is a cross-chain DEX that enables fast, low-cost exchange across multiple blockchains. It uses hash time-locked contracts (HTLC) and out-of-order exchange processing processes to complete exchanges in minutes, much faster than traditional cross-chain bridges.
Currently, Meson supports exchanges between 16 blockchains, such as Ethereum, Solana, BNB Chain, Polygon, Avalanche, and L2 rollups like Arbitrum and Optimism.
Meson also plans to support more tokens, covering more stablecoins and assets, such as BTC/ETH. In the future, Meson will continue to integrate various rollup and non-EVM chains.
2.4.2 Best Features
● Direct exchange of native assets — Meson supports direct exchange between major stablecoins such as USDT and USDC without the need for wrapped tokens as intermediaries. This greatly simplifies the exchange process.
●Security - Although it uses existing bridging technology, Meson is not strongly dependent on any one bridge. Funds do not need to be locked in the bridge's pool, improving utilization while ensuring security.
2.4.3 Principle of Operation—Trading Cycle
Step 1: The user creates an exchange request off-chain, specifying the exchange amount, source chain, target chain and token type.
Step 2: To issue a request, the user needs to sign the message and authorize the Meson contract to lock the matching exchange amount and fee. The signed request is broadcast to the LP network.
Step 3: LP verifies the request and calls the "postSwap" method on the source chain to publish and bind the exchange. Meson transfers funds and locks them for 1-2 hours.
Step 4: LP calls the "lock" method on the target chain to lock the exchange funds for 20 minutes (temporarily).
Step 5: The user verifies steps 2 and 3, then creates and broadcasts a signature to release the funds.
Step 6: Anyone can call the "release" method on the target chain. If the signature is valid, the locked funds will be paid to the designated payee.
Step 7: LP uses the release signature to call "executeSwap" on the source chain to obtain the initial funds deposited by the user.
Step 8: LP can withdraw funds or transfer funds to the liquidity pool on the source chain, and the transaction is completed.
Note: Users can currently exchange up to 5000 USDC/USDT from each chain to Solana via Meson. In addition to the 0.05% service fee, an outbound fee of 0% to 0.1% may be charged depending on the source chain. Therefore, the total cost of exchange to Solana is between 0.05% and 0.15%. That means the fee ranges from $0 to $7.50, depending on the number of tokens exchanged and the source chain.
2.5 Jupiter Bridge Comparator
In September 2023, Jupiter launched Bridge Comparator to make it easier for users to transfer funds from other chains to Solana. Bridge Comparator provides users with a platform where they can compare quotes for bridge and cross-chain exchange orders in one place.
The feature has been widely praised by the Solana community for its simplicity, chain compatibility (9 chains) and the detailed display it provides on output prices, expected times, gas usage and bridge provider fees.
Currently, Bridge Comparator is a front-end aggregation solution, that is, it shows users the best bridge options for their orders and directs them to the recommended bridge provider’s interface to execute the order. In the future, Jupiter may extend the Bridge Comparator into a Bridge Aggregator and add the ability to execute orders from the Jupiter interface.
Separately, in early December, Jupiter announced the integration of Wormhole Connect on its bridge page, allowing users to bridge ETH, WETH or WBTC from Ethereum to Solana with zero slippage. After this integration, the next step is integration with Circle CCTP.
2.6 Synapse — Powered by deBridge
Synapse recently launched a cross-chain exchange frontend for Solana, powered by deBridge. This move can be viewed as an interim check to assess user needs and collect user behavior data related to Solana bridging activities before committing resources to building a feature-rich Solana deployment.
Observers might speculate that Synapse's timeline for such a development deployment might coincide with Solana's CCTP release. This speculation is based on the fact that Synapse already utilizes CCTP for USDC transfers across the EVM chain.
2.7 Phantom’s Cross-Chain Swapper — Powered by LI.FI
In November 2023, Phantom released Cross Chain Swapper, an in-wallet bridging feature that allows users to transfer funds from EVM chains such as Ethereum and Polygon to Solana (and vice versa). It has a built-in Refuel feature that allows users to send additional gas tokens in the same transaction.
In-wallet cross-chain exchange is a powerful primitive. They offer users the convenience of finding the best rates among bridging solutions for cross-chain exchange orders, without even leaving the wallet interface. This reduces the time users spend looking for a suitable bridge solution and makes it easy for everyone to move assets to Solana.
Cross-Chain Swapper uses LI.FI at the bottom level to implement bridge transactions. Currently, LI.FI uses:
●Allbridge supports bridge transactions between Ethereum <> Solana. (Note: Support for Circle’s cross-chain transfer protocol CCTP is currently being tested on devnet)
●cBridge, Across, Hop, Polygon PoS, Allbridge, Stargate and CCTP support bridge transactions between Ethereum <> Polygon.
Additionally, Phantom also integrates it with DEX aggregators such as 0x on the EVM side and Jupiter on Solana, allowing users to bridge and exchange in the same process.
In the future, the entire cross-chain exchange process will most likely be supported by LI.FI, as it already supports 30 DEX and multiple DEX aggregators on the EVM side, and has coverage with Solana-native aggregators like Jupiter on its roadmap integrated. This will further reduce Phantom’s maintenance overhead and expand the range of assets that users can swap directly onto Solana.
Note: Phantom charges a 0.85% fee on certain exchange pairs. In addition, users may need to pay a fee to the bridge provider (such as Allbridge), which is usually around 0.3% of the transfer amount, depending on the provider. (LI.FI does not charge any fees).
3. Interesting developments in Solana interoperability scenarios
Solana has always been focused on building the most advanced blockchain to enable fast and low-cost transactions. This approach distinguishes it from other blockchain ecosystems such as Ethereum and Cosmos, which emphasize interoperability with other ecosystems. Therefore, Solana’s connection to other blockchains is subject to certain limitations.
Recognizing this difference, several interesting project developments have recently emerged aimed at improving Solana's interoperability. If these initiatives reach their full potential, they could significantly enhance the ability of Solana-based tokens and applications to interact with the broader ecosystem.
Let’s take a deeper look at these promising developments that are paving the way for a more connected Solana ecosystem to form.
3.1 Circle’s Cross-Chain Transfer Protocol (CCTP)
The Cross-Chain Transfer Protocol (CCTP) developed by Circle enables native transfers of USDC stablecoin tokens between different blockchain networks.
CCTP simplifies the process of transferring USDC between networks by burning and minting tokens directly on the relevant blockchain, thus bypassing the need for a bridging token variable. The introduction of CCTP on Solana is expected to further simplify the transfer process of USDC from other chains to Solana.
CCTP on Solana is currently in the devnet testing phase and is scheduled to go live in early 2024. The Solana community eagerly awaits its release and widespread adoption.
3.2 Solana <> Bitcoin interoperability
One of the great innovations of 2023 is the introduction of an experimental fungible token standard, the BRC-20 Token Standard for the Bitcoin blockchain, which is a joint effort between Ordinals (NFTs on Bitcoin) and 2021’s Use cases for Taproot network upgrade implementation.
The growing popularity of BRC-20 tokens such as ORDI has fueled the development of several bridges designed to connect Bitcoin to other blockchain ecosystems. These bridges allow users to spend their BRC-20 tokens on the EVM chain and Solana, expanding the utility and accessibility of Bitcoin-based tokens. One of these bridges is the SoBit protocol released in December 2023.
Solana <> The Bitcoin interoperability project is not limited to BRC-20 tokens. For example, SolLightning is a cross-chain DEX that allows users to swap between USDC/SOL on Solana and native BTC on the Bitcoin network. Interestingly, THORChain, the largest native Bitcoin exchange platform, stated that it will add support for Solana in the near future, which may significantly increase BTC liquidity and activity on Solana.
Zeus Network is a messaging protocol and another interesting project contributing to Bitcoin-Solana interoperability. Apollo, the first product built on the Zeus network and set to launch soon, will allow users to stake their native Bitcoin and receive zuBTC, a 1:1 pegged token available in the app on Solana use.
3.3 Trust-minimized cross-chain interaction with Tinydancer and Sovereign Labs
Light clients play an important role in the blockchain ecosystem, allowing users to securely access and interact with the blockchain without synchronizing the full blockchain data. This is very advantageous because light clients have lower resource requirements and sync faster than full nodes.
A key feature of light clients is their ability to verify transactions and proofs from other blockchains in a trust-minimized manner. For example, in cross-chain interactions, light clients can verify that transactions are correctly included in the source chain based on the proof provided. This proof can be verified without directly interacting with the source chain, enabling secure cross-chain functionality.
Currently in the Solana blockchain, light clients cannot locally verify transaction inclusion without fully downloading the block data. This is expected to change soon with Tinydancer, a project building light clients that recently proposed SIMD-0052 (Consensus and Proof of Transaction Verification) improvements to address this limitation. This will improve the current functionality of SPV (Simplified Payment Verification).
Additionally, Sovereign Labs recently developed a proof-of-concept for an on-chain light client on Solana without requiring changes to the current structure.
In the future, this light client functionality can also facilitate improvements in interoperability solutions between blockchains, such as IBC and Layerzero. By lowering trust requirements and enabling light client verification, it makes it easier to transfer assets between blockchains without the need for a full node.
However, the work is in its early stages and will require more detailed research and more development work before it can be fully implemented.
3.4 IBC supported by Guest blockchain concept on Solana
The guest blockchain concept proposed by Picasso is enabling IBC on Solana. This approach aims to enable interoperability between blockchains and light clients that currently do not support proof of state, a key requirement for the Inter-Blockchain Communication (IBC) protocol.
The Guest blockchain runs as a smart contract within the host blockchain. In doing so, it will enhance host capabilities to support interoperability protocols such as IBC. This integration facilitates trust-minimized cross-chain interactions without requiring changes to the underlying protocol of the host blockchain.
Additionally, the guest blockchain extends the functionality of the host blockchain by implementing the functionality required by IBC. For example, it stores data in Merkle trees to generate state proofs. It also organizes blocks into epochs and selects validators to generate new blocks. Validators sign blocks using proofs of state that are forwarded to other connected blockchains via
