Acknowledgements: This work is a collaborative effort co-authored by LI.FI and Four Pillars. Special thanks to Heechang Kang for his contributions to this report.

Key Takeaways

• Solana’s ecosystem is experiencing a significant uptick in bridging activity, especially since November 2023. Bridges like Wormhole, Allbridge, and deBridge (early supporters of the Solana ecosystem) are well-positioned to benefit from this surge.
• The user demand to move funds to Solana has sparked a rush for liquidity bridges to expand to Solana. In December alone, Synapse, Meson, and Hashflow added routes to Solana. Soon, the need for aggregation platforms like Jumper to support Solana will become apparent.
• Wormhole offers the most robust offering for developers in terms of messaging protocols, while deBridge’s DLN is emerging as the preferred liquidity bridge for asset transfers.
• Very few applications on Solana feature built-in bridging, but the landscape is evolving. Phantom and Jupiter are at the forefront of this change, embedding bridging functions within their services.
• Upcoming projects like Circle’s CCTP, Wormhole’s cross-chain queries, and Jumper Exchange’s cross-chain swaps will enhance Solana’s connectivity with the broader blockchain ecosystem. Moreover, innovations such as Tinydancer’s light clients and Picasso’s IBC guest blockchain concept can potentially enable trust-minimized cross-chain interactions.

Introduction

With the growing buzz around Solana and increasing activity in the ecosystem, more developers and users are looking to interact with it. Now is the perfect time to present an in-depth guide on the bridges that enable connectivity to Solana.

This report is the definitive resource for anyone interested in understanding Solana’s bridging landscape. It is targeted to fulfill the intents of two main groups: developers aspiring to build cross-chain applications using messaging protocols, and users moving assets to Solana to find the next 1000x memecoin, hoping it will be their ticket to early retirement.

The report is organized into three main sections:

• Part I: A Deep Dive into Messaging Protocols on Solana – This section analyzes the messaging protocols currently operating in the Solana ecosystem. It examines the technical workings, operational mechanisms, and the inherent trade-offs associated with these protocols. The objective is to arm developers with the critical knowledge to select the messaging protocol that aligns with their application’s needs while shedding light on the origin, functionality, and security for the users interested in learning more about the apps they use.
• Part II: Applications for Cross-Chain Swaps to Solana – The second part of the report explores the various applications that enable bridging and cross-chain swaps to and from Solana. It discusses how these apps work, their best features, their impact on the user experience, and how they contribute to the liquidity and accessibility of Solana’s ecosystem.
• Part III: Interesting Developments in Solana’s Interop Scene – The final section highlights the latest and most notable developments in Solana’s interoperability landscape. It covers new projects, interesting new releases by existing protocols, and other initiatives that can positively influence how Solana interacts with the broader blockchain ecosystem in the future.

With the stage set, let’s dive in!

1. Part I: A Deep Dive into Messaging Protocols on Solana

This section examines the design, security, and trust assumptions of different messaging protocols that connect Solana with the broader ecosystem. It highlights their unique features and tradeoffs with a thorough analysis of their architecture.

Here, we will cover the following:

• An Overview of the Messaging Protocol – This part of the deep dive will include the project’s suite of products, performance statistics, key network effects and security information.
• How It Works: Transaction Lifecycle – The process of sending user funds from one blockchain to another via the liquidity network built on top of the messaging protocol, understanding the different components of the bridge design.
• Trust Assumptions & Tradeoffs – Design tradeoffs made by each messaging protocol and their potential consequences.
• Risk Analysis: Architecture Design & Security Considerations – a summary of the messaging protocol’s architecture, implementation, operational, and network security based on the Cross-Chain Risk Framework built by LI.FI and Consensys.
• Community & Resources – all the resources to follow the project’s updates and learn more about its offerings.

1.1 Wormhole

1.1.1 An Overview

Launched in October 2020, Wormhole is a messaging protocol designed to enable developers to build cross-chain native applications spanning multiple chains. Wormhole began as a hackathon project with the objective of finding a solution to allow blockchains to ‘talk to one another.’

Initially incubated and supported by Jump, the first version of Wormhole (Wormhole V1) was primarily focused on establishing a bi-directional token bridge between Ethereum and Solana. As the project progressed, Wormhole evolved into a generic message-passing protocol that connected several chains in the ecosystem. This evolution aligned with its broader vision of becoming a foundational layer upon which developers could construct diverse cross-chain applications. Consequently, Wormhole V1 was phased out, and Wormhole network was introduced in August 2021.

Product Offerings

Several cross-chain native applications and product offerings have been built atop Wormhole, including products by the Wormhole team itself, in response to the growing needs of a multi-chain ecosystem:

• Portal – a lock and mint token bridge that allows users to bridge tokens and NFTs across chains supported by Wormhole. It is one of the first applications to use Wormhole’s messaging functionality and has contributed significantly to its growth.
• Connect – a widget that allows developers to integrate a Portal-like interface for token bridging within their application. It gives developers a simple and quick way to add bridging capabilities to their apps.
• Gateway – an application-specific blockchain purpose-built to improve the connectivity of Cosmos-based appchains with the wider ecosystem. It uses a liquidity router, which serves as a unified liquidity layer across Cosmos chains. This tool is beneficial for developers aiming to attract users and liquidity to their Cosmos appchain and for users seeking to bridge funds to the Cosmos ecosystem. Gateway is currently live for developers and available for users via Portal.
• Queries – a tool for cross-chain data queries that enables applications to read onchain data from any EVM chain within the Wormhole ecosystem. This data is verified by a ⅔ supermajority of 19 Wormhole Guardians. This product is still in the early stages of development with Synthetix expected to be an early adopter.

These products are further bolstered by multiple developer-friendly solutions and features by the Wormhole team (many of which are now built and maintained by contributors of the newly formed Wormhole Foundation), such as:

• xAssets – assets that can be bridged across any Wormhole supported chain without any slippage. Example: Pyth Network recently launched their $PYTH governance token as a Wormhole xAsset, making it accessible for users across 27 chains.
• Automatic relayers – a network of relayers that can deliver messages across any Wormhole supported chain. This feature allows developers to build cross-chain applications on Wormhole without setting up and maintaining their own off-chain relayers.
• Wormholescan – a cross-chain block explorer and analytics platform covering the Wormhole ecosystem. This tool can be used to track cross-chain transactions and understand the network activity across the Wormhole ecosystem.

Network Effects

Given Wormhole’s early and continued focus on the Solana ecosystem, it’s not surprising that Solana ranks as the most actively used chain on Wormhole in terms of number of transactions.

Interestingly, Wormhole’s volume stats are dominated by bridging flows to/from Terra – an ecosystem that’s no longer seeing any significant development and activity. Currently, volume is majorly distributed across Ethereum, Solana, Sui, followed by EVM L1 chains and rollups.

Factors contributing to Wormhole’s growth and positioning as one of the top messaging protocols in the ecosystem include:

• 200+ projects building on Wormhole – Wormhole has established significant distribution in the ecosystem with several applications using it to build apps for use cases like liquidity bridges (Allbridge, Mayan, Magpie), multi-chain tokens (PYTH), token standards (Nexa), in-app bridging with Connect (Astroport, Uniwhale, YouSUI), cross-chain deposits (Friktion, PsyOptions, Aftermath Finance).
• Wormhole x NFTs – Wormhole’s cross-chain NFT standard was popularly used by Dust Labs to migrate their NFT collections DeGods and y00ts from Solana to Ethereum and Polygon respectively. This NFT standard is also used by the Aptos NFT bridge to allow developers and users to bridge NFTs to/from the Aptos network.
• Wormhole’s $50M ecosystem fund – the $50M ecosystem fund offers the much needed financial support to developers building cross-chain applications that leverage Wormhole’s messaging infrastructure. Managed and operated by Borderless Capital, this fund draws on funding support from notable investors including Jump Crypto, Polygon Ventures, and the Solana Foundation, among others.
• xGrant program – In early 2023, Wormhole introduced the xGrant program, designed to support developers, researchers, and founders. This initiative provides not just financial assistance, but also mentorship and resources to facilitate the development of innovative projects. The grants cover various expenses such as software development, marketing, team costs, and other aspects of project growth and expansion.
• Bitcoin on Solana with tBTC – Threshold Network introduced tokenized Bitcoin (tBTC) on Solana using Wormhole to mint the asset. This marked tBTC’s first expansion to a non-EVM ecosystem and enabled users to use Bitcoin in the Solana DeFi ecosystem.
• Wormhole x Uniswap – Wormhole’s positioning as one of the secure messaging protocols in the ecosystem got a significant boost with Uniswap’s Bridge Assessment Committee endorsing Wormhole for all cross-chain deployments, following a comprehensive evaluation of six different bridges. Additionally, Uniswap’s active use of Wormhole for cross-chain messaging, particularly with chains like Celo, further solidifies Wormhole’s standing as a dependable choice for secure messaging needs.
• Wormhole x Circle CCTP – Wormhole has successfully integrated Circle’s Cross-Chain Transfer Protocol (CCTP), making it accessible to other applications through Connect and to users via Portal. The anticipated launch of CCTP on Solana is generating significant interest, with teams like Jupiter already declaring their plans to support it in their applications through Wormhole.
• Wormhole’s $225M funding round at a $2.5B valuation – Wormhole recently secured a significant funding milestone, completing a $225 million round at a valuation of $2.5 billion. This substantial investment underscores the strength of Wormhole’s team, the widespread adoption of its product, and the overall quality it offers. The funding announcement has also caught the attention of airdrop farmers, who are now closely comparing Wormhole with LayerZero, recognizing Wormhole as “a worthy contender in the interoperability sector.” With the ongoing Solana airdrop season and Wormhole’s strategic initiatives, such as offering an ‘early’ role to Discord users adding fuel to the fire, it is likely to see significant attention from airdrop farmers in the near future.

Security Check

Audits – Wormhole’s architecture consists of several key components like the Guardian nodes and smart contracts for different chains and execution environments. The various parts of their tech stack have undergone 22 audits in total from Neodyme, Kudelski, Trail of Bits, CertiK, Runtime Verification, OtterSec, Zellic. It’s important to note that while we’re counting each entry as a separate audit, it’s likely these contract specific audits were part of a single bigger audit of Wormhole’s tech stack.

Bounty – Since September 2022, Wormhole has run a $2.5M bounty program on Immunefi, primarily focusing on the security of Wormhole’s smart contracts and Guardian nodes

Security Breach – In February 2022, Wormhole network experienced a security breach as an attacker ‘exploited a signature verification vulnerability in the Wormhole network to mint 120k Wormhole-wrapped Ether on Solana’, resulting in an estimated loss of approximately $326 million. The vulnerability was fixed within a few hours and Wormhole was back online shortly after, with Jump providing necessary funds to cover the shortfall.

Following the exploit, the Wormhole team announced the following security initiatives for the future:

• Continuous audits – comprehensive and ongoing audits of the Wormhole codebase have been conducted and planned to prevent future vulnerabilities.
• Advanced monitoring tools – features like accounting mechanisms and monitoring tools to isolate risks across chains and detect threats early to ensure dynamic risk management is possible.
• Bug bounty program: Wormhole launched a bug bounty program on Immunefi, which was launched soon after the exploit.

In light of these security upgrades, Uniswap’s Bridge Assessment Committee acknowledged Wormhole’s efforts in their report, stating:

“Subsequent to the exploit, Wormhole has made substantial enhancements to its practices such as improved implementation processes, clearer incident response plan and robust unit testing. These improvements are commendable and demonstrate the protocol’s growth and maturity.”

Wormhole has added several security features to its stack including:

• Global accountant – this tool monitors the total circulating supply of all Wormhole assets across all chains. Essentially, it prevents any blockchain from moving around more assets than they are actually allowed to.
• Governor – Complementing the Global Accountant, the Governor tracks the inflows and outflows of assets across all chains. It has the authority to delay suspicious transfer and limit the impact of exploits by enabling Guardians to hold Wormhole messages for 24 hours if their value is excessively large. It can also be used as a rate limit for the notional flow across a chain. Additionally, it serves as a rate limiter for notional flow across chains, which is particularly beneficial for newer, less tested chains. The Governor’s limits can be adjusted as a chain’s ecosystem matures.
• Open-source repositories – By making its code repositories open-source, Wormhole effectively lowers barriers for white-hat hackers to identify and report vulnerabilities.
• Comprehensive monitoring via Guardians – Wormhole Guardians are specialized validator companies with expertise in running, monitoring, and securing blockchain operations. They continuously track activity at the blockchain and smart contract level and ensure security of the Wormhole network via tools like the Governor.
• ZK coming to Wormhole – Wormhole is actively working on integrating ZK verification for messages to its stack.

Growth Stats

1.1.2 How It Works — Transaction Lifecycle

The process of transferring messages from a source chain to a destination chain via Wormhole’s architecture is intricate yet straightforward at a high level. Here’s a simplified breakdown:

1) Emission of Message: Each message originates from a ‘Core Contract’ on the source chain.

2) Verification and Signing by Guardians: This message is then authenticated and signed by 19 Guardians in an off-chain process. A message is considered authentic only if it receives signatures from at least 2/3rds (13 out of 19) of the Guardians.

3) Relay to Destination Chain: Once verified and signed, the message is relayed to the Core Contract on the destination chain.

Looking more closely, we see several key components working together to ensure secure cross-chain messaging:

Let’s dive deeper into how messages are verified by Wormhole’s Guardian network:

Step 1: The Core Contract on the source chain emits the message.

Step 2: Guardians observe and verify the message’s authenticity.

Step 3: The Guardians wait for the finality of the source chain before signing the hash of the message body, attesting to its validity.

Step 4: The signatures from each Guardian are compiled into a multisignature document known as the Verifiable Action Approvals (VAAs).

Step 5: Relayers then transfer the VAA to the Core Contract on the target chain.

Note: the ‘Spy’ observes all messages passing through the Guardian network and records them in a storage system, like an SQL database, for analysis and further use.

1.1.3 Trust Assumptions & Tradeoffs

Here’s a list of notable trust assumptions and tradeoffs made by Wormhole:

• External verification by a set of validators – Wormhole’s proof-of-authority system inherently trusts that Guardians can be trusted to verify transactions and that over 2/3rd of Guardians will not collude at a certain time. In case the majority of Guardians collude, users’ funds could be stolen.
• Censorship risk – 7/19 Guardians can collude to censor messages.
• No slashing mechanisms for Guardians – In Wormhole’s system, there is no bonding or slashing mechanism implemented for the Guardians. However, accountability is a key aspect of the network’s design. Any malicious activity can be directly traced back to the specific Guardian. This direct attribution means that in cases of fraud or misconduct, the involved Guardian could potentially face legal liabilities and suffer significant reputational damage.
• Permissioned Guardian network – Adjustments to the Guardian set, whether it involves adding new Guardians or removing existing ones, are governed by a 13/19 signature scheme.

1.1.4 Risk Analysis: Architecture Design & Security Considerations

1.1.5 Community & Resources

You can learn more about Wormhole through the following:

• Official Website
• Docs
• Wormhole for Developers
• Github
• Explorer
• Medium
• Wormhole Scan

You can stay updated about its community by following them on:

• Twitter
• Discord
• Telegram
• @wormholecrypto">Youtube

1.2 Allbridge

1.2.1 An Overview

Launched in July 2021, Allbridge is a blockchain bridge that started within the Solana ecosystem. It was originally named Solbridge as its focus at launch was to expand Solana’s presence in the ecosystem by connecting it with other chains. Over time, the protocol expanded its scope beyond Solana and rebranded to Allbridge.

Product Offerings

Allbridge Classic is the first iteration of Allbridge. It enables asset transfers across 20 chains, including both EVM and non-EVM chains like Solana and Stellar. This version of the protocol has been responsible for handling the majority of Allbridge’s volume.

In June 2022, Allbridge launched Allbridge Core, a new-age bridging platform focusing on cross-chain stablecoin swaps. This new version addresses the pain points of the legacy version, particularly the multi-step, time consuming process of bridging tokens via an Allbridge-wrapped implementation and then swapping them into the desired asset.

Allbridge Core simplifies the bridging experience by focusing on stablecoin swaps. Since most bridging activity involves stablecoins, Allbridge Core is able to cater to most user demands while keeping the product simple and lightweight. Presently, Allbridge Core features 11 liquidity pools, enabling stablecoin swaps across 7 chains.

Additionally, Allbridge Core introduces unique features, such as:

• Support for multiple messaging protocols – In addition to supporting cross-chain message transfer via Allbridge, Allbridge Core also supports other messaging protocols like Wormhole. This integration enables it to support unique chains available through Wormhole and provides an alternative/fallback option for chains already supported by Allbridge.

Furthermore, Allbridge Core has recently integrated Circle’s Cross-Chain Transfer Protocol (CCTP). This addition enables Allbridge Core to support USDC transfers across CCTP-supported chains without the need for maintaining liquidity pools on these chains. Moreover, users can choose from three different messaging protocols, each offering varying transfer fees and times.

Currently, CCTP support is only available on EVM chains. However, this will change soon as CCTP already supports Solana on devnet and is set to launch on mainnet in the near future.

• Extra gas on the destination chain – This feature addresses users’ ‘cold start’ issue when bridging assets to a new chain. With this, users can simply bridge some extra funds to pay for gas on the destination chain with this feature.

The ‘extra gas’ feature is slowly becoming a standard in the multi-chain ecosystem. For instance, in the Solana ecosystem, Phantom uses it as the ‘Refuel’ function for their ‘Cross-Chain Swapper’, via the LI.FI integration that uses Allbridge Core under the hood.

Beyond user-facing products like Allbridge Classic and Allbridge Core, Allbridge offers a white-label bridging solution called Allbridge BaaS. This allows projects to use Allbridge’s cross-chain messaging functions and launch a bridge setup specifically for their token. Allbridge charges a one-time fee of $20K for setting up this bridge.

Network Effects

From original product focus on Solana to winning Solana hackathons in 2021, Allbridge’s roots are deeply tied to the Solana ecosystem. This emphasis on Solana has proven advantageous, as Solana remains the most active chain on Allbridge. Since its launch, Allbridge Classic has seen over $1.44 billion in volume from more than 190,000 transactions on Solana, generating $535K in fees on Allbridge Classic alone.

Other major ecosystems contributing to Allbridge’s growth include common names across all bridging platforms, like Ethereum, Avalanche, BNB Chain, and Polygon. Interestingly in the case of Allbridge Core, Tron network is an ecosystem that has seen significant traction.

Notably, popular Layer 2 solutions like Arbitrum and Optimism, which usually dominate EVM-focused bridge statistics, are absent from this list. It is also worth mentioning that Allbridge doesn’t support several major and emerging Layer 2s, such as Base, zkSync, and Linea, with only USDC on Arbitrum being supported on Allbridge Core.

Recently, Allbridge Core was integrated by LI.FI, gaining access to LI.FI’s distribution of over 120 protocols for cross-chain swaps. Additionally, Allbridge is currently the sole bridge provider for EVM <> Solana transactions in Phantom’s Cross-Chain Swapper feature. This exclusivity allows Allbridge to benefit from high transaction volumes until other bridge providers are added.

Moreover, Allbridge presented the testnet demo of the CCTP integration at Breakpoint 2023. This strategic partnership with Circle as launch partners for CCTP on Solana will also be beneficial for the protocol.

Security Check

Audits – Allbridge’s architecture has been audited 5 times. By Hacken in September 2021 (Audit score - 10), by Kudelski Security in May 2022, by Cossack Labs in September 2022), by Hacken in Feb 2022 (Audit score - 9.8), and by CoinFabric in July 2023.

Bounty – Allbridge has an open bounty on HackenProof with rewards ranging from $100 - $4,000.

Security breach – In April 2023, Allbridge Core faced a security breach due to a flash loan exploit on the BNB chain, resulting in a loss of $650K. Attackers exploited a logic flaw in the withdrawal function, manipulating swap prices in the pool.

The Allbridge team recovered ‘most of the stolen funds’ and compensated the shortfall, reimbursing affected users who completed an application form. Post-attack, the protocol relaunched with the following fixes and security features:

• Fixing the liquidity calculation on deposits and withdrawals – extensive testing was conducted.
• Introduction of Rebalancer Authority via special accounts – this tool will allow the team to rebalance pools in extreme circumstances and emergencies by using the bridge without paying fees.
• An automatic shutdown feature for extreme pool imbalances, like a stablecoin losing its peg.
• Ability to manually shutdown the bridge to improve reaction time in case of unexpected issues.
• A public repository that highlights the team’s efforts to become more open source and invite white hat research to review the bridge’s contracts.

According to L2BEAT, Allbridge Core ‘contains a number of core, unverified smart contracts’ which can put the user’s funds at risk in case they contain malicious code.

It’s important to note that following the security breach incident, Allbridge Core’s contracts were redeployed. The main contracts have now been verified. Additionally, the contracts of Allbridge Classic are also verified.

However, the L2BEAT team has noted that certain bridge contracts remain unverified. The Allbridge team explains this as a complication arising from an overlap of the older Core contracts, which were in place before the security incident, and the contracts associated with Allbridge Classic. Steps are being actively taken by Allbridge to address and clarify this discrepancy on the L2BEAT website, ensuring a clearer and more transparent understanding for everyone.

Growth Stats

1.2.2 How It Works — Transaction Lifecycle

Allbridge Core

Here’s how assets are transferred from the source chain to destination chain via Allbridge Core’s architecture:

Step 1: Users send assets to the liquidity pool on the source chain, where they are locked.

Step 2: These assets are swapped into Virtual Tokens (VT) which represent their dollar value.

For example, when a user sends 100 USDC, the amount is converted into VT based on the current exchange rate of VT to USDC.

Step 3: The Virtual Tokens with the transaction information are transferred to the destination chain via the chosen messaging protocol.

The validators of the messaging protocol verify that the funds have been locked on the source chain and swapped accurately into ‘Virtual Tokens’.

Step 4: The message arrives on the destination chain and triggers the smart contract.

Step 5: The smart contract swaps the Virtual Tokens to the desired tokens from the liquidity pool on the destination chain and sends them to the user’s address.

While this might seem like different steps on different chains, it all happens in one click for the user.

Allbridge Classic

Allbridge Classic supports a broader range of tokens, like aeUSDC (Allbridge Ethereum Wrapped USDC), which are minted by the bridge.

Here’s how assets are transferred from the source chain to destination chain via Allbridge Classic’s architecture:

Step 1: Users send funds to Allbridge’s smart contract on the source chain.

At this step, users can send two types of assets:

1) Native 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 burned by the smart contract on the source chain.

Step 2: A transaction record is created, prompting a validation request to the Allbridge validators.

Step 3: Validators verify the locking of funds on the source chain.

Step 4: Once verified, validators issue a signature to the user.

Step 5: The user then forwards this signature to the smart contract on the destination chain.

Step 6: The funds are transferred to the user. The process varies depending on the type of asset that the user is expected to receive on the destination chain.

For example, if it’s:

1) Native assets – the assets are unlocked from the destination chain’s smart contract and transferred to the user’s wallet.

2) Wrapped assets – the assets are minted by the smart contract on the destination chain and transferred to the user’s wallet.

1.2.3 Trust Assumptions & Tradeoffs

Here’s a list of notable trust assumptions and tradeoffs made by Allbridge:

• External verification by a set of validators – Allbridge relies on third-party validators to verify the user’s transactions, depending on the underlying messaging protocol used (Allbridge or Wormhole or CCTP).
• Small validator set – Allbridge’s validator set consists of only 2 validators. The two validators can potentially collude to pass malicious messages and steal users’ funds.
• Censorship risk – a single validator in Allbridge’s validator set can censor messages.
• Permissioned validator set – the validators operating in the system are run and/or chosen by the Allbridge team.
• No slashing mechanisms – there are currently no slashing penalties imposed on validators to disincentivize them from colluding or censoring.
• The Allbridge team can censor users – while special accounts will give the Allbridge team more control to react promptly in case of emergencies, it can also be misused to wrongly censor user deposits, withdrawals and swaps.

1.2.4 Risk Analysis: Architecture Design & Security Considerations

1.2.5 Community & Resources

You can learn more about Allbridge through the following:

• Official Website
• Allbridge Core docs
• Allbridge Classic docs
• Medium
• Messari on Allbridge Core
• Messari on Allbridge Classic
• Allbridge Classic Analytics
• Allbridge Core Analytics

You can stay updated about its community by following them on:

• Twitter
• Telegram
• Discord
• Reddit

1.3 deBridge

1.3.1 An Overview

Launched in August 2021, deBridge is an interoperability protocol that enables transfers of messages and liquidity across chains. The project began as a hackathon project in April 2021 at the Chainlink Global Hackathon and later that year, it secured $5.5M in funding.

deBridge’s expansion into the Solana ecosystem began with a $20,000 grant from the Solana Foundation in June 2021. Setting itself apart from the protocols discussed earlier, deBridge initially catered exclusively to EVM-compatible chains. It wasn’t until June 2023 that deBridge went live on to Solana, becoming one of the early players to achieve this feat.

Product Offerings

deBridge’s product suite encompasses a range of cross-chain applications that capitalize on its message-passing capabilities:

• deSwap Liquidity Network (DLN) – DLN is a liquidity network that enables cheap and fast cross-chain swaps across any chain supported by deBridge. Unlike traditional models that rely on liquidity pools, DLN utilizes market makers who provide liquidity on-demand across chains, enabling asset transfers with zero TVL. To ensure ample liquidity for large sized cross-chain orders, the deBridge team collaborates with sophisticated market makers such as RockawayX and Fordefi.
• dePort – Serving as a lock-and-mint bridge, dePort allows applications to create deBridge-wrapped assets, known as deAssets, on various chains. These minted assets are backed one-to-one by the original tokens on the source chain, ensuring asset integrity across networks.

Beyond direct user applications for cross-chain swaps, deBridge also extends these products to applications and other projects, including wallets, through an API for seamless integration. In addition, bloXroute Labs is in the process of developing an SDK to integrate DLN into their Blockchain Distribution Network. This integration will enable bloXroute users (including MEV searchers, institutional DeFi traders, and various projects) to execute DLN-powered cross-chain swaps.

Furthermore, deBridge provides deBridge IaaS (Interoperability-as-a-Service), a subscription-based offering that enables EVM and SVM blockchains to integrate deBridge’s products for their ecosystem. This service is priced at $11,000 per month for monthly subscriptions or $10,000 per month for quarterly subscriptions. Neon Labs has the distinction of being the first user of this service.

Network Effects

deBridge’s growth since launch has been steady and consistent. The protocol has recently witnessed a surge in usage, particularly with the uptick in activity on Solana. The Solana <> Ethereum route has quickly become the most frequented corridor on DLN. The strategic move by the deBridge team to allocate resources towards integrating Solana support has evidently paid off, with immense potential for further growth.

DLN’s capability for near-instant settlement of cross-chain orders has rapidly established it as the preferred platform for users looking to transition to Solana from other blockchains. Recently, DLN celebrated a significant milestone, surpassing $10 million in daily volume for the first time – a testament to its growing popularity and an indicator that this achievement is likely just the beginning, given the Solana ecosystem’s accelerating momentum.

In addition to individual users, deBridge is gaining traction in the business-to-business (B2B) sector, with a growing number of applications on Solana integrating deBridge’s products into their offerings. Some of the most notable examples include MoonGate, Birdeye, and Jupiter bridge comparator tool, among others.

This trend suggests that deBridge is strategically positioned to capitalize on the Solana ecosystem’s expansion in the upcoming cycle.

Security Check

Audits – deBridge has demonstrated a strong commitment to security, with its smart contracts on both EVM chains and Solana successfully undergoing 15 comprehensive audits. These audits have been conducted by reputable security firms, including Halborn, Neodyme, Zokyo, and Ackee. Detailed reports and findings from these audits are accessible on deBridge’s GitHub repository for those seeking in-depth information.

Bounty – Since January 2022, deBridge has run a $200,000 bounty program on Immunefi focusing on ensuring the security of its smart contracts.

Growth Stats

DLN emerged as a standout performer among liquidity networks in Q4 2023, uncannily mirroring the growth trajectory of the Solana ecosystem’s TVL and volumes during the same period.

To contextualize DLN’s performance in the final quarter, here’s a quick snapshot of its performance in Q4 against its cumulative performance throughout 2023 (from April 1, 2023, to December 31, 2023):

1.3.2 How It Works — Transaction Lifecycle

Here’s how assets are transferred from the source chain to destination chain in a trade across DLN:

Step 1: A user, referred to as the Maker, initiates an order on the source chain. This is done by invoking the DlnSource.createOrder() function, where they provide the transaction details and lock the input tokens in the contract.

Step 2: Market Makers, known as Takers, monitor these orders off-chain. When they identify an order that aligns with their criteria (such as profitability and token availability), they proceed to fulfill it. This is achieved by executing the DlnDestination.fulfillOrder() on the destination chain, where they provide the tokens as specified by the Maker’s request.

Step 3: Upon receipt of the order, DlnDestination validates the details and completes the transaction by dispatching the tokens to the receiver’s address on the destination chain. The order is then marked with a ‘fulfilled’ status.

Step 4: The Taker who completed the order then calls DlnDestination.sendUnlock(). 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 proceeds to release the previously locked input tokens, transferring them to the Taker who fulfilled the order.

1.3.3 Trust Assumptions & Tradeoffs

deBridge, like any interoperability protocol, operates with certain trust assumptions and tradeoffs that users should be aware of:

• External verification by a set of validators – deBridge’s network is secured by a relatively small validator set of 11 nodes. For a transaction to be confirmed, it requires signatures from at least two-thirds of the validators, meaning 8 out of 11. This structure introduces the possibility that collusion among 8 validators could compromise users’ funds.
• Censorship risk – There is a potential risk of censorship if a minority of validators, specifically 5 out of 11, decide to collude. This could lead to the intentional blocking or delaying of message processing.
• No slashing mechanisms for validators – Although deBridge’s documentation references the future implementation of delegated staking and slashing mechanisms as key to protocol security, these features are not yet active. Without slashing, there are no direct economic consequences to deter validators from engaging in fraudulent or malicious behavior. However, it must be noted that the current validator set is permissioned and selected by the deBridge team and are established entities, potentially subject to legal action and reputational harm, which may act as an indirect form of accountability.
• Destination token contract can be maliciously upgraded by validators – According to L2BEAT, the admin for all upgradable proxy smart contracts is a Gnosis Safe with 5 / 8 threshold. Thus, user funds can be stolen if the destination token contract is maliciously upgraded or not securely implemented

Note: It is important to highlight that deBridge is on a path towards decentralization. The concerns mentioned, such as the absence of slashing mechanisms and the permissioned nature of the validator set, are expected to be addressed 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 & Security Considerations

Important Note: We could not get specific details from the deBridge team concerning their testing procedures, vulnerability response plans, and security monitoring systems, despite reaching out for clarification. However, the majority of the information provided in the table remains accurate and was validated by the deBridge team in 2022 when we conducted an in-depth review of their protocol. According to the deBridge team, “there have been no changes in the architecture” since the last deep dive was published.

1.3.5 Community & Resources

You can learn more about deBridge through the following:

• Official Website
• Docs
• DLN Docs
• deBridge Security
• Getting started with deBridge
• deExplorer
• Analytics
• Github
• Medium
• Blog

You can stay updated about its community by following them on:

• Twitter
• Discord
• Telegram
• Reddit

1.4 Comparative Analysis of the Messaging Protocols & their Liquidity Networks

After analyzing the designs and features of the different messaging protocols, now we will summarize their architectural and implementation security. The goal is to provide a snapshot comparison of the security considerations related to the different messaging protocols and enable developers to pick one to build on or use based on the trade-offs they’re comfortable with and the security guarantees they like.

In the analysis, we will see a comparison based on the following metrics:

• Consensus mechanism – How does the protocol determine the validity of messages?
• Validator set collusion – Minimum number of validators that can collude to steal funds.
• Censorship resistance – Minimum numbers of signers that can censor a message passing through the protocol.
• Permissionless-ness – Is the validator set permissionless? Can anyone become a validator and contribute to determining the validity of messages?
• Slashing mechanism – Is there an active slashing or bonding mechanism to disincentivize validators from acting maliciously?
• Smart contract upgradeability – Are the protocol’s smart contracts upgradeable? If yes, who can upgrade them?
• Bug bounty – Maximum amount a whitehat hacker can receive as a reward for finding critical vulnerabilities in the protocol’s code for a bug bounty.
• Audits – Number of audits each protocol has gone through (the more, the better).

Here’s the messaging protocols on Solana stack up against each other:

Up next, we will analyze each liquidity network’s performance until December 31, 2023 by breaking it down into three key metrics:

• Unique users – How many distinct users have used the liquidity network since launch?
• Transaction count – How many transactions have been executed using the liquidity network since launch?
• Bridged volume – How much volume has passed through the liquidity network since launch?

Here’s how the performance of the liquidity networks built on top of the messaging protocols stacks up against each other:

2. Part II: Applications for Cross-Chain Swaps to Solana

Building on the foundation laid in the previous section, where we explored various messaging protocols and their potential for developers to create cross-chain applications, we now turn our attention to one of their most prominent uses: liquidity networks. This section shifts focus to the different liquidity networks that connect Solana with the wider ecosystem, enabling users to transfer funds across chains easily.

Moreover, we will look at some interesting applications and features being launched around liquidity aggregation, aimed towards making it simple for users to find the best liquidity network for their needs.

Our aim is to spread awareness about the different options available for users to swap across Solana and the EVM ecosystem.

With this in mind, let’s get started!

2.1 DLN (deSwap Liquidity Network)

2.1.1 Overview

Powered by deBridge, DLN is a cross-chain trading protocol that facilitates the creation and fulfillment of orders across chains.

The protocol is architecturally divided into two principal layers: the protocol layer and the infrastructure layer.

Protocol Layer – This layer consists of smart contracts deployed on each supported chain. These contracts allow market participants to interact in a decentralized environment, enabling them to create, monitor, and settle orders:

• Makers – users that create orders by locking input tokens in the DlnSource smart contract on the source chain.
• Takers – market makers that fulfill orders by supplying output tokens to the DlnDestination contract on the destination chain.

Once an order is fulfilled,the DlnDestination contract communicates with the DlnSource contract via the infrastructure layer. This process releases the input tokens and transfers them to the taker, thereby completing the cross-chain trade.

Infrastructure Layer – This layer handles cross-chain messaging through deBridge’s validators. It enables the DlnDestination contract to reliably communicate the fulfillment of an order to the DlnSource contract, finalizing the settlement.

2.1.2 Best Features

• Zero slippage scroll all order sizes – Trades on DLN have zero slippage, meaning users get the price they expect regardless of order size. This feature effectively addresses the common issue of slippage associated with traditional liquidity pools.
• Rapid settlement – Trades on DLN settle much faster than legacy liquidity bridges due to its asynchronous design and ability to leverage Market Maker’s liquidity on demand.
• Rapid scalability – DLN’s design allows it to process high volumes of trading since it is not limited by liquidity pools or bridge throughput. The transaction volume on DLN has been increasing steadily over the last month.

Note: Every transaction on DLN is subject to a minimum fee of 8 basis points (bps). This fee is split evenly between the DLN protocol and the taker who completes your order, with each receiving 4bps. However, if a user places a limit order, the fee allocated to the taker who fulfills your order could exceed 4bps.

2.2 Portal

2.2.1 Overview

Powered by Wormhole, Portal is an integral component of the Wormhole network, facilitating the transfer of assets between blockchains.

The Portal bridge is engineered to enable the secure and seamless transfer of both fungible and non-fungible tokens across blockchains.

When assets pass through Portal, the original token is locked into a smart contract on the originating chain, while a new Portal-wrapped counterpart is created on the destination chain. This counterpart can be redeemed for other native tokens available on that chain.

2.2.2 Best Features

• Access to multiple ecosystems – users can move assets across many different ecosystems and markets that Wormhole supports. This expands the reach and utility of the user’s assets.
• Security – Wormhole’s network of Guardian nodes and signed messages provide a robust security model to validate cross-chain transactions. Moreover, changes and upgrades to Wormhole are managed transparently through on-chain governance by the Guardian network.

2.3 Mayan Finance

2.3.1 Overview

Powered by Wormhole, Mayan Finance is a cross-chain swap protocol that allows users to swap tokens across different blockchains with a single click.

Currently, Mayan supports swaps between Ethereum, Solana, Avalanche, and Polygon networks. However, the protocol has plans to expand support to more blockchains in the future.

2.3.2 Best Features

• Cross-chain swaps – Mayan allows users to swap tokens from one blockchain to another supported blockchain with a single transaction.
• English auction mechanism – Mayan holds an English auction mechanism to facilitate cross-chain trades. When a user initiates a swap, Mayan holds an auction on the destination blockchain to find the best rate for the swap. This ensures users are given the highest bid price for their orders.
• Supported tokens – 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 like SDKs and widgets that allow other apps to directly embed Mayan’s swap functionality into their own platforms. This enables any project to offer cross-chain token swaps through Mayan’s infrastructure.

2.3.3 How It Works — Transaction Lifecycle

Step 1: Initiation on Source Chain

A user starts the process on the source chain by interacting with the Mayan Swap Bridge. They initiate a cross-chain swap and set the parameters of the auction, which include the minimum output and a deadline.

Step 2: Auction on Solana

The transaction then moves to Solana, where an auction is held. The winner of the auction becomes responsible for executing the swap on the Solana network.

Step 3: Receiving Assets on Destination Chain

Finally, the user receives the native assets on the destination chain. These assets are sent along with the specified amount of gas required for the transaction.

Assets are swapped across different blockchain networks, utilizing the Solana network as an intermediate auction platform. The Mayan Program on Solana handles the auction and swap mechanics, while the Mayan Swap Bridge interfaces with Ethereum Virtual Machine (EVM) compatible chains for initiating and completing the swap. The destination could be another EVM chain or even the Solana chain itself.

Note: Users are required to pay a relayer fee which covers the cost of gas and the relayer’s effort of conducting the transaction for the user. This fee changes dynamically based on the asset and chain combination. Should a transaction fail, the relayer fee is significantly reduced.

2.4 Meson

2.4.1 Overview

Meson Finance is a cross-chain DEX that enables fast, low-cost swaps across multiple blockchains. It uses hash time-locked contracts (HTLCs) and out-of-order swap processing to finalize swaps in just minutes, much faster than traditional cross-chain bridges.

Currently, Meson supports swaps between 16 blockchains like Ethereum, Solana, BNB Chain, Polygon, Avalanche as well as layer 2 rollups like Arbitrum and Optimism.

Meson also plans to expand token support to include more stablecoins and assets like BTC/ETH. In the future, Meson will continue integrating different rollups and non-EVM chains.

2.4.2 Best Features

• Direct exchange of native assets – Meson supports direct swaps between major stablecoins like USDT and USDC without needing wrapped tokens as intermediaries. This simplifies the process.
• Security – While utilizing existing bridge technologies, Meson is not strongly dependent on any single bridge. Funds do not need to be locked in bridge pools, increasing utilization while maintaining security.

2.3.3 How It Works — Transaction Lifecycle

Step 1: A user constructs a swap request off-chain specifying the swap amount, source chain, destination chain and token type.

Step 2: To publish the request, the user signs a message, authorizing the Meson contract to lock the swap amount + fee for matching. The signed request is broadcast to the LP network.

Step 3: An LP validates the request and calls the “postSwap” method on the source chain to post and bond the swap. Meson transfers the funds and locks them for 1-2 hours.

Step 4: The LP calls the “lock” method on the destination chain to lock the swap funds for 20 minutes (tentatively).

Step 5: The user validates steps 2 and 3, then constructs and broadcasts a signature to release funds.

Step 6: Anyone can call the “release” method on the destination chain. If the signature is valid, the locked funds are paid to the designated recipient.

Step 7: The LP uses the release signature to call “executeSwap” on the source chain, obtaining the initial funds deposited by the user.

Step 8: The LP can withdraw or transfer the funds to their liquidity pool on source chain, completing the transaction.

Note: Users can currently swap a maximum of 5000 USDC / USDT from various chains to Solana through Meson. An outbound fee ranging from 0% to 0.1% may apply, depending on the source chain, in addition to a service fee of 0.05%. Consequently, the total cost for swaps to Solana can range from 0.05% to 0.15%. This translates to a fee of $0 to $7.50, which varies based on the amount of tokens being swapped and the source chain.

2.5 Jupiter Bridge Comparator

In September 2023, Jupiter launched Bridge Comparator with the goal of making it easier for users to move funds to Solana from other chains. The Bridge Comparator offers users a platform where they can compare the quotes on bridging and cross-chain swap orders to Solana in a single place.

The feature has been widely lauded by the Solana community for its simplicity, chains supported (9) and the details it offers in terms of showing output price, expected time, gas usage, and bridge provider’s fee.

Currently, the Bridge Comparator is a front-end aggregation solution, i.e., it shows users the best bridging option for their order and directs them to the recommended bridging provider’s interface for execution. In the future, it’s possible that Jupiter extends the Bridge Comparator into a Bridge Aggregator, adding the functionality of being able to execute orders from the Jupiter interface itself.

Moreover, earlier in December, Jupiter announced the integration of Wormhole Connect on its bridge page, enabling users to bridge ETH, WETH, or WBTC from Ethereum to Solana with 0 slippage. This integration is expected to be followed by the integration of Circle CCTP when it goes live on Solana.

2.6 Synapse – Powered by deBridge

Synapse recently launched a front-end for cross-chain swaps to Solana that uses deBridge under the hood. This move can be seen as a temp check to assess user demand and collect data on user behavior related to Solana bridging activities before investing resources into building a feature-packed Solana implementation.

Observers might conjecture that Synapse’s timeline for developing such an implementation could coincide with the launch of CCTP on Solana. This speculation builds on the fact that Synapse already leverages CCTP for USDC transfers across EVM chains for SynapseX.

2.7 Phantom’s Cross-Chain Swapper – Powered by LI.FI

In November 2023, Phantom launched Cross-Chain Swapper, an in-wallet bridging feature that allows users to move funds to Solana from EVM chains like Etheruem and Polygon (and vice versa!). It comes with an in-built Refuel feature which allows users to send extra gas tokens in the same transaction.

In-wallet cross-chain swaps are a powerful primitive. They offer users the convenience of finding the best rates across bridging solutions for their cross-chain swap order without even leaving the wallet interface. This reduces the time users have to spend finding the right bridge and makes it simple for anyone to move assets to Solana.

The Cross-Chain Swapper uses LI.FI under the hood to enable the bridging transactions. Currently, LI.FI uses:

• Allbridge for Ethereum <> Solana. (Note: Support for Circle’s Cross-Chain Transfer Protocol (CCTP) is presently being tested on devnet)
• cBrigde, Across, Hop, Polygon PoS, Allbridge, Stargate, and CCTP for Ethereum <> Polygon.

Moreover, Phantom combines this with DEX aggregators like 0x on the EVM side and Jupiter on Solana to enable users to bridge and swap in the same flow.

In the future, it’s likely that the entire cross-chain swap flow will be enabled by LI.FI as it already supports 30 DEXs and multiple DEX aggregators on the EVM side, and has the integration of Solana-native aggregators like Jupiter on its roadmap. This will further reduce the maintenance overhead for Phantom and broaden the range of assets users can directly swap into on Solana.

Note: Phantom imposes a 0.85% fee on certain swap pairs. Additionally, a user may have to pay bridge provider (like Allbridge) fees, which are generally around 0.3% of the transferred amount and vary by provider. [LI.FI does not charge a fee].

3. Part III: Interesting Developments in Solana’s Interop Scene

Historically, Solana has focused on building a state-of-the-art blockchain that can enable fast and cheap transactions. This approach differentiated it from other blockchain ecosystems, such as Ethereum and Cosmos, which have placed significant emphasis on enabling interoperability with other ecosystems. Consequently, Solana’s connectivity with other blockchains has been somewhat limited.

Recognizing this gap, there have recently been several interesting developments aimed at improving Solana’s interoperability capabilities. These initiatives, if realized to their full potential, could significantly enhance the ability of Solana-based tokens and applications to engage with the broader ecosystem.

Let’s dive into some of these promising development efforts that are paving the way for a more interconnected Solana ecosystem.

3.1 Circle’s Cross-Chain Transfer Protocol (CCTP)

The Cross-Chain Transfer Protocol (CCTP), developed by Circle, enables the native transfer of USDC stablecoin tokens between different blockchain networks.

By directly burning and minting tokens on the involved blockchains, CCTP simplifies the process of moving USDC between networks, thus bypassing the need for bridged token variants. The anticipated introduction of CCTP on Solana promises to further ease the transfer of USDC to Solana from other chains.

CCTP on Solana is currently on devnet and is planned to go live in early 2024. It’s launch is eagerly anticipated by the Solana community and is expected to see widespread adoption.

Learn more about stablecoin bridges like CCTP: LI.FI: The Stablecoin Bridge Almanac 2023

3.2 Solana <> Bitcoin Interoperability

One of the novel innovations of 2023 was the introduction of an experimental fungible token standard known as the BRC-20 token standard for Bitcoin blockchain, a use-case made possible by Ordinals (NFTs on Bitcoin) and the Taproot network upgrade in 2021.

The rising popularity of BRC-20 tokens like $ORDI has spurred the development of several bridges designed to connect Bitcoin with other blockchain ecosystems. These bridges allow users to leverage their BRC-20 tokens on EVM chains and Solana, expanding the utility and accessibility of Bitcoin-based tokens. One such bridge is the SoBit Protocol which @SobitBridge/sobit-bridging-brc20-assets-to-solana-and-fueling-the-inscription-markets-growth-55a9a3b0e703">launched in December 2023.

Solana <> Bitcoin interoperability projects are not limited to BRC-20 tokens. For example, SolLightning is a cross-chain DEX that enables users to swap between USDC and SOL on Solana and native BTC on the Bitcoin network. Interestingly, in a significant development for the ecosystem, THORChain, the biggest swap platform for native Bitcoin, indicated it will be adding support for Solana in the near future, which could substantially increase liquidity and activity for BTC on Solana.

Zeus Network, a messaging protocol, is another interesting project contributing to the Bitcoin-Solana interoperability landscape. Apollo, the first product built on Zeus network, is set to launch, enabling users to stake their native Bitcoin and receive zuBTC, a 1:1 pegged token that can be used across applications on Solana.

3.3 Trust Minimized Cross-Chain Interactions with Tinydancer and Sovereign Labs

Light clients play an important role in blockchain ecosystems by allowing users to securely access and interact with the blockchain without needing to sync the full blockchain data. This is advantageous because light clients have lower resource requirements and faster synchronization speeds compared to full nodes.

One key characteristic of light clients is their ability to verify transactions and proofs from other blockchains in a trust-minimized manner. For example, in a cross-chain interaction, the light client can verify that a transaction was correctly included in the source chain based on a proof provided. This proof can be validated without interacting directly with the source chain, thereby enabling secure cross-chain functionality.

Currently in the Solana blockchain, there is no way for light clients to locally verify transaction inclusion without fully downloading block data. This is expected to change soon with Tinydancer, a project building the light client and recently proposed SIMD-0052 (Consensus and Transaction Proof Verification) improvement that addresses this limitation. This will improve the current functionality of SPV (Simple Payment Verification).

Also, Sovereign Labs has recently built a proof of concept on the on-chain light client on Solana, without needing to modify the current structure.

In the future, this light client functionality could also facilitate improved inter-blockchain interoperability solutions like IBC and layerzero. By reducing trust requirements and enabling light client validation, it makes transferring assets between blockchains easier without needing full nodes.

However, this work is still in its early stages and requires more detailed research and development to be fully implemented.

Learn more about Tinydancer: Tinydancer Docs

Learn more about Sovereign Labs Light Client: Solana Light Client Repo

3.4 IBC on Solana via the Guest Blockchain Concept

The guest blockchain concept, by Picasso, is enabling IBC in Solana. This approach is designed to enable interoperability between blockchains that do not currently support state proofs and light clients, which are key requirements of the Inter-Blockchain Communication (IBC) protocol.

A guest blockchain operates as a smart contract within a host blockchain. By doing so, it enhances the host’s functionality, enabling it to support interoperability protocols such as IBC. This integration facilitates trust-minimized cross-chain interactions without the need to alter the foundational protocols of the host blockchain.

Moreover, the guest blockchain extends the functionality of the host blockchain by implementing features required for IBC. For example, it stores data in a Merkle trie to generate state proofs. It also organizes blocks into epochs and selects validators to produce new blocks. Validators sign blocks with state proofs that are relayed to other connected blockchains through a trustless relay. If validators misbehave, proofs can be submitted to slash their stake held on the guest contract.

The guest blockchain’s deployment as a smart contract means that the host blockchain’s core structure remains untouched, making this solution highly adaptable for blockchains that are not yet IBC-ready, such as Solana, NEAR, and TRON. Composable Finance is spearheading proof-of-concept projects for both Solana and NEAR to showcase this interoperability in action.

Once linked with IBC-compatible blockchains, the guest blockchain enables the movement of assets, data, and value across previously siloed chains. This breakthrough paves the way for new types of cross-chain applications, all leveraging IBC within the Solana ecosystem.

Learn more about the guest blockchain concept: Crossing the Cross-Blockchain Interoperability Chasm

3.5 Ethereum Wallets on Solana with Moongate’s SDK

MoonGate provides a SDK that aims to make it simple for developers to integrate Ethereum wallet functionality into their Solana-based dApps. By leveraging MoonGate, developers can tap into Ethereum’s community and liquidity while still constructing dApps on Solana’s faster and more affordable platform.

Through its developer-friendly SDK, MoonGate allows dApp builders to seamlessly include existing Ethereum wallets and features with just a few lines of code. This removes much of the complexity associated with blockchain integration.

The SDK is also planned to empower dApps with capabilities like embedded on-ramping and swapping. MoonGate is planning to feature an in-app instant bridge with deBridge for smooth transfers of assets between Ethereum and Solana networks within dApps. This enhances the user experience.

Learn more about MoonGate: Enter the MoonGate

3.6 Cross-Chain Queries by Wormhole

Wormhole Queries is a new primitive introduced by Wormhole that allows for reading data of other blockchain data.

With Wormhole Queries, integrators can now submit query requests to the Wormhole Guardian network to retrieve cross-chain data in a pull-based manner. The Guardians process the requests and publish the results, allowing integrators to verify and consume the data on-chain quickly and securely. This introduces significant benefits like simplified cross-chain development, lower gas fees, and rapid data retrieval within seconds. It leverages the existing security of Wormhole Guardians for attested data retrieval.

Some key potential use cases of Wormhole Queries include providing real-time cross-chain price feeds for applications. This allows platforms to access up-to-date price information from various blockchains. Wormhole Queries also enables cross-chain asset verification, allowing users to prove ownership of assets on one chain and use them in applications on other chains.

Isn’t this just Oracle you may ask? We believe it is more than that.

Current oracle solutions are limited in their cross-chain functionality. They primarily focus on providing off-chain price data to blockchains. Retrieving on-chain data from other chains has also been limited.

With Wormhole Query, applications may one day have access to a wide range of interoperable data sources spanning multiple blockchains, going beyond prices. The use cases can be found in how @quasar.fi/introducing-interchain-queries-d6243e7b45cf">ICQ (Interchain Query) is used in the Cosmos ecosystem.

In addition, projects like Herodotus and Axiom aim to store historical block data on-chain in a provable and decentralized way. As these protocols mature, they can act as an “Ethereum Library,” and with Wormhole Query, the library will be accessible from Solana.

3.7 Omnichain Token Standards by Nexa Network

As there are many blockchains and rollups launching with different architectures and specifications, the token standards and liquidity are fragmented. This problem is evident in the Ethereum ecosystem, where interchain token standards like OFT, Layerzero, and xERC20 (aka. ERC-7281) are used.

Currently, Nexa Network is developing a solution to address this issue. At the moment, Nexa Network only supports EVM. However, as it utilizes Wormhole and is backed by the Wormhole team, there are plans to add support for Solana in the near future.

The CAT Standard is a token standard developed by Nexa Network. It enables tokens to be bridged across multiple blockchains while preserving fungibility and issuer control.

CAT provides a standardized approach for bridging tokens across blockchains while maintaining sovereignty for issuers and a unified user experience with fungible, secure tokens. This approach is very similar to what xERC20 (ERC-7281) is doing in the EVM ecosystem.

Key points about CAT:

• Token issuers deploy CAT contracts on each chain and whitelist bridges to mint tokens from those contracts. The deployment can be seamlessly done using its dashboard.
• All tokens bridged by different whitelisted bridges are fully fungible, avoiding liquidity fragmentation seen today.
• Issuers can set minting limits for each bridge, allowing granular security control over bridged tokens.
• Users experience seamless bridging without slippage between chains.

Learn more about CAT: Upgrading the Chain-Agnostic Token standard to be bridge-agnostic.

3.8 Hyperlane: Enabling Permissionless Interoperability for Solana and SVM Chains like Eclipse

Hyperlane is a messaging protocol that enables permissionless interoperability. This feature is critical for the expansion of blockchain ecosystems, as it allows anyone to permissionlessly deploy the Hyperlane tech stack on any blockchain, thus unlocking enhanced network connectivity.

Recent developments have seen Hyperlane collaborate with Eclipse on an SVM compatible implemenation of its tech stack. This implementation is currently live in production with Nautilus Chain and is slated for integration with Eclipse’s infrastructure in the near future.

The implications of this development for the Solana ecosystem and the broader adoption of SVM are noteworthy. With the ability to permissionlessly deploy Hyperlane on any blockchain, new SVM chains don’t need to wait for existing messaging protocols to add support for their chain. Instead, they can proactively deploy Hyperlane and establish connectivity with the broader ecosystem.

Learn more about Hyperlane: Hyperlane Deep Dive / Deploy Hyperlane to a new chain

3.9 Cross-Chain Swaps by LI.FI on Solana and SVM Chains

LI.FI is a protocol that aggregates liquidity across multiple blockchains by integrating bridges, DEXs, DEX aggregators, and solvers.

When a swap is requested, LI.FI’s routing algorithm determines the optimal bridge and DEX path to use. Factors like speed, fees, reliability are considered to find the highest performing route.

LI.FI recently launched in Solana’s ecosystem with Phantom as its launch partner. This can improve Solana by providing a seamless and secure connection with other blockchain ecosystems as projects can integrate the LI.FI API to offer seamless cross-chain functionality without managing direct bridge connections.

Additionally, LI.FI has developed a solution that will enable support for chains compatible with the Solana Virtual Machine (SVM) in the future. This development suggests that LI.FI’s cross-chain swap capabilities will extend to users and applications on SVM-compatible chains, such as Eclipse. Consequently, applications operating on SVM chains will be able to tap into liquidity from any chain, streamlining user onboarding by integrating LI.FI’s API, SDK, and Widget. Moreover, users will have the option to swap and bridge to SVM chains directly through Jumper.exchange.

Learn more about LI.FI’s expansion to Solana and SVM chains: Phantom Integrates LI.FI to Enable In-Wallet Cross-Chain Swaps to Solana / Docs to Integrate LI.FI on Solana

Closing Thoughts

Messaging protocols and liquidity networks built on top of them are critical pieces of infrastructure for any ecosystem. They can be thought of as infrastructure investments in a country’s economy – just as highways, ports, and railways are critical for economic growth by facilitating trade and movement, these protocols and apps are vital rails for the growth of Solana’s ecosystem, enabling secure flow of assets and information.

We believe these cross-chain money legos will be pivotal to Solana’s continued success as they have a profound impact on the onboarding experience for users coming from different DeFi ecosystems.

We hope this report brings clarity on how messaging protocols work and awareness around the different liquidity networks available for those looking to become a manlet.

With that, we encourage you to reach out to our team with any thoughts, feelings, or opinions about this report.

Thank you for your time :)

Disclaimer: This article is only meant for informational purposes. The projects mentioned in the article are our partners, but we encourage you to do your due diligence before using or buying tokens of any protocol mentioned. This is not financial advice.

Disclaimer：

1. This article is reprinted from [LI.FI]. All copyrights belong to the original author [Arjun Chand]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.